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In this Issue 

The components of a typical telecommunications network usually come from 
different vendors and the networks are usually distributed geographically. To 
manage these large-scale networks, a standards-based telecommunications 
network management system must be in place. Standards define the interfaces 
that enable telecommunications equipment manufacturers, system integrators, 
and service providers to develop network management applications that allow 
their products to intemperate in a heterogeneous telecommunications network 
environment These vendors need a development platform and a toolset to take 
care of the underlying standards-compliant requirements for management 
applications, 

The first nine articles in this issue describe HP products targeted to meet the needs of telecommunications 
application developers. The article on page 6 introduces the HP OpenView Distributed Management (DM) 
Platform, a software foundation that provides the services for building standards-compliant telecommu- 
nications management network applications. Tiie article describes tbe Telecommunications Management 
Network (TMN> from ITU-T (International Telecommunications Union-Telecommunications), the features 
of the OSI-based version of HP OpenView DM, and the architecture of the new CORBA-based version of 
the HP OpenView Platform. CQRBA (Common Object Request Broker Architecture) is a service that en- 
ables objects to make and receive requests and responses in an object-oriented distributed environment. 

Developers creating applications to run in a distributed, heterogeneous telecommunications environment 
should not be concerned about what system their applications may be running on. They should be able to 
target their applications to run on a software architecture that handles all telecommunication management 
and control functions for distributed applications. The article on page 17 describes the HP Distributed Pro- 
cessing Environment, which provides infrastructure services that facilitate rapid development, deployment, 
and management of distributed applications in the telecommunications arena. 

Network management relies on information, especially information from network elements such as 
bridges, routers, servers, and gateways. The article on page 22 describes the HP Open Element Man- 
agement Framework (OEMF), which is the implementation of the ITU-T recommendation that covers fault 
management, performance management, and other third-party applications OEMF makes possible the 
detection, isolation, and correction of the abnormal operation of a telecommunications network. OEMF 
includes the HP OpenView Fault Management Platform (FMP) r which is a platform and utility tool for 
managing alarms from multlvendor devices and network element managers. 

When a fault occurs in a telecommunications system it can cause an event storm of several hundred 
events per second for tens of seconds. HP OpenView Event Correlation Services (ECS) helps operators 
determine the underlying cause for the thousands of events presented to them. ECS is made up of two 
components: the ECS engine, which executes a set of downloaded rules that control the processing of 
event streams, and the ECS Designer, which enables interactive development of correlation rules, ECS is 
described in the article on page 31. 

TMN uses an object-oriented paradigm, and its management principles are based on the OSI (Open Sys- 
tem Interconnection) standard. Thus, in the TMN model, network and system resources are modeled as 
objects, called managed objects. Telecommunications management application developers need to 
specify and model these managed objects to create management applications. The article on page 43 
describes the HP OpenView GDMO (Guidelines for the Definition of Managed Objects) Modeling Toolset, 
which is an integrated set of tools that enable developers to use a graphical user interface to specify 
and create a file containing managed objects. GDMO is an ITU-T recommendation that defines how 
network objects and their behavior are to be specified. 

Once the developer has created the GDMO specifications for the managed objects, the next step is to 

develop agent applications that maintain and provide access to the objects and the manager applica- 
tions that manage the network through request and response processing. This is the agenfmanager 
model of network management. The HP OpenView Managed Object Toolkit (page 52) uses the contents 
of the GDMO specification file to automatically generate OSl-conformant executable agent applications. 
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The toolkit also provides a C++ interface that encapsulates the complexities of the underlying protocols, 
providing assistance in the development of management applications. 

The managed objects are stored in a database called the Management Information Base (MIS). The 
objects in the MIB are defined by GDMD, organized hierarchically, and related by containment. Under- 
standing this data and the operations required to access it are essential for developers implementing 
TMN management applications. The article on page 62 describes a prototype that addresses some of 
the requirements of TMN application developers by allowing them to explore the available management 
data and make enough sense of it to construct and deploy pieces of management applications. 

Once the manager and agent applications have been created, the next step js to test both of these applica- 
tions simultaneously. To help with this task, the new HP QpenView Agent Tester Toolkit (page 771 generates 
tests that allow a deveioper to execute these tests individually or as a set- During agent development, the 
Agent Tester Toolkit is used to simulate requests sent from a manager, transmit these requests over the 
network to the agent, and then receive and process the responses from the agent 

The TMN architecture defines five network management layers in which telecommunications applications 
can fit. The two top layers are called the business management layer and the service management layer 
The business management layer contains functions that are responsible for the whole enterprise, such 
as budgeting and product planning, and the service management layer contains functions that are 
responsible for managing sen/ices provided to customers, such as service transactions and billing. The 
article on page 70 describes an application called HP OpenPM, which fits into these two layers, HP 
OpenPM is an open, enterprise-capable, object-oriented business process flow management system 
(BPFM). HP OpenPM is a middleware service that provides the enabling technologies for defining and 
managing workflow in areas such as resource allocation, task initialization and data exchange, and end- 
to-end communication and security. 

Telecommunications networks and distributed computing environments rely on reliable and consistent 
storage management strategies. Today, storage management strategies involve more than just more disk 
drives. They also include storage management and different types of storage devices for offline, nearline, 
and online data storage. The article on page 81 provides an overview of HP hardware and software 
products, services, and partners that provide storage management solutions. 

Even though processor speeds continue to improve dramatically, they are barely keeping up with the 
increasing numbers of concurrently running applications and CPU-intensive applications with higher 
throughput requirements. Additionally as the number of interconnects between systems and I/O devices 
continues to increase, I/O channels become bottlenecks to system performance. For all these reasons, 
todays parallel bus architectures are reaching their limits. In the search for a higher-performance serial 
interface, HP chose Fibre Channel because it overcomes the limitations mentioned above by supporting 
sustained gigabit data transfer rates. The article on page 99 describes Tachyon, which is HP's gigabit 
Fibre Channel chip. The article on page 94 presents a technical description of Fibre Channel. 

C.L Leath 
Managing Editor 



Cover 

An artistic rendition of telecommunications, showing a satellite antenna in the background and an HP 
OEMF network map and alarm viewer for a mobile network in the foreground. 



What's Ahead 

The December issue will feature the design of the HP 83480 digital communications analyzer for SONET/ 
SDH testing, the HP E5200A broadband service analyzer for ATM testing, HP SmartCtock technology and 
products for using the Global Positioning System as a time reference, and the HP HEOS-8000 Series sur- 
face mount reflective optica! shaft encoders. A pair of papers will describe a new, radially staggered IC 
bonding technology, and a special section will celebrate the thirtieth anniversary of HP Laboratories. 
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A Platform for Building Integrated 
Telecommunications Network 
Management Applications 

Telecommunications companies today are faced with rapid technological 
change, large heterogeneous environments, and a greater need to provide 
customers with products that ensure reliable, cost-effective network 

service. This means that these companies need a platform that has a 
visionary strategy that enables them to develop standards-compliant 
network management solutions for a continually changing environment. 

by Prabha &. Chadayammuri 



The telecommunications industry is going through phenome- 
nal growth and change. This growth has made telecommu- 
nications networks essenl ial lo the daily activities of the 
enterprise and individuals, li lias also given rise to the- need 
Tor better ways to manage and maintain heterogeneous and 
i n u 1 1 i ve 11 d or i ictwo r ks. 

Network management includes the operations, administra- 
tion, maintenance, and provisioning (OAM&P) functions 
required to monitor, interpret , and control a network and 
rlic services it provides. When networks started to be used 
beyond the academic community and before deregulation 
and privatization of the telephone industry, there were fewer 
vendors, thus fewer niultivendoi management issues. Also, 
the rate ol introduction of new network technologies was 
much slower, these conditions meant that network manage- 
ment could lie ad hoc and vendor-specific. Today, issues 
such as m ulti vendor networks and equipment, the need lo 
automate certain network management tasks, and the rapid 
Integration of new technologies have driven ihc need to 
.standardize telecommunications network management. 

Since the early KIKfls, the standardization bodies have been 
developing and specifying a collection of standards for 
managing teleconimuni cations networks, A portion of these 
standards, dealing with open systems, is contained in die 
X.7xx series of standards defined by the ITU-T (Interna- 
tiona I Tel ecomnumi cat iot is I. ■ n i o 1 1 — Tel ec omnumications) . 
Another series of standards, the M.;Jxxn series from ITU-T. 
defines a model known as the Telecommunications Manage- 
ment Network (TUN). 1 

TMN is based on the Open Systems lnu-n onuection (OSl i 
system* maiingenu-til model, which is set of standards thai 
define the rules for i >i ■■■ ■■ ^sing and transferring data over 
networks.- Such systems are Called Qgm system*. Although 
not intrinsically part of TMN, ( )S1 systems management stan- 
dards were developed jointly by the ISO and ITU standards 
bodies. 

All uj ihese standards, no matter how worthy, are simply 
collections of well- written guidelines with out a pin I form and 
tools to build network management solutions. Choosing a 



network management platform is a critical strategic deci 
sion lhai has long-term implications. The development of 
large-scale telecommunications management systems 
nqiiin sa signifieanl investment of resources. Solutions, 
once deployed, will be supported Tor many years. 

For equipment manufacturers and systems integrators, the 
network management foundation must enable rapid devel- 
opment of applications that can differentiate and add value 
to their products, For telecommuiucations service providers, 
the network management foundation must enable rapid 
deployment of new services that improve ( -■ unpetitiveness 
and new operations that increase efficiency, 

HP Open View products provide the platform and enabling 
technologies required for network man age mem solutions 
for today's telecuinminiH :-at U his environment, 

EIP OpenView DM 

The HP OpenView Distributed Management (DM) platform 
is a soft ware platform for designing portable, standards- 
based systems for telecommunications management (see 
Fig. I). HP OpenView DM products are focused on meeting 
the reliability, performance, distribution, and standards 
needs of telecommunications equipment manufacturers, 
service providers, and system integrators. The MP OpenView 
DM platform offers the following features for developing 
TMN applications. 

Standards Support, The I IT OpenView DM products support 
protocol, object, and service specifications defined by ITV f 
OSL \ < )jieu ' : , the Internet Engineering Task Force (IETF) 
(mi S\MP i Simple Network Management Protocol), and the 
Network Yhmagement Fonmi (NMF)' ! 

There is also full support for network management protocols 
CM IP [Common Management Information Protocol), RFC 
1006 (TCP/IP), and SNMR 4 * 

Open Systems, The IIP OpenView DM platform is built on an 
open systems architecture, enabling solutions to run on a 
variety of hardware platforms, Nalive support is implemented 
for IIP 9000 workstations and servers running the HP-CX* 
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Fig. 1. The main components of 



operating system and Sun SPABC workstations running the 
Solaris and Sun( IS operating systems. Support for HP Open- 
View is a 1st > provided on other hardware and software plat- 
forms, 

Postmaster, Tin post in; i esas ihe integral ion point 

for management protocol stacks such as CMIP and SNMP, 
management APIs, and related Facilities (e.g., routing, 
events, and association control), I he postmaster provides 
distributed message routing and access to applications and 
services through standard management protocols. Finally, 
Hie postmaster reliabfy creates and manages associations 
; connections), maps objects in network addresses and pro- 
h« rol stacks^ and routes revests from manager systems and 
responses from managed systems (agents). 

Event Services. HPQpenVJeM MM provides aset of services 
that management applications can use to control eveni and 
alarm messages from diverse network elements and systems, 
li includes a mediation service thai collects, stores, filters 
and extracts messages and an alarm management service 
that displays and correlates alarm messages and invokes 
external applications based on alarm data. Alarm maxiai 

meal and event (correlation sin u -r rihed in the 

articles on pages 22 and 31 respecth i -\\ 

HP Distributed Processing Environment (DPE). the IIP DPE 
provides an Information Networking Architecture UNA) 
compliant platform foi telecommunications services and 
operations systems, Trader services and an Ail framework 
simplify the development and deployment 61 disti tbuted 
telecommunications applications, III* DPE is described in 
the article <*n page 17. 

Graphical User Interface The ill* < >j m m i \ it m graphical 

user Interlace (GUT) provides network operators and admire 

■ us wiih a consistent view < sf tin- managed environment 



and seamless mtegrat ion t rf management functions, regard- 
less of vendi » '.or managed object type; HP Open View win- 
dows provides a common interface that simplifies the tfevel 
opmenl and use of management applications. Finally, the 
HPU|>rn\ieu windows qjj\ is the key integration poini tor 
HP< >pen\ it-w applications, 

Modeling Toolset. The I II * < JpenVievv 61 Mi > 1 1 inidHines for 
the Melmilinn of Managed f Jbjeris/' Modeling Toolset is an 
integrated suite ot software tools for designing and analyzing 
i objects used in network management applications. < rDM* > is 
an [SO standard thai describes fl consistent methodology for 
I- , M H - managed objects in TMN applications. 

The BPOpenVlew GDMI I Modeiing Toolset has a forms- 
based GUI thai enabled developers to create GDMt i specific 

rations and export ilum as ASCII files ha use by tin* next 
implication in the tool chain, the Managed Ob ject Toolkii, 
The HPOperiVtoi GDMO Modeling Toolset is described in 
the article on page 13. 

Managed Object Toolkit. The IIP i JpenView Managed I t^ect 
Toolkit is a C++ code generator thai accelerates the devel- 
opment ofGDMG-based manager and agent applications 

cribed betovs? \. The managed object toolkit Includes an 
infiasTmeMjre iiiai provides a collection of reusable objects 
that handle l MIS operations socfi as GET, SET. and action. 

Agent application development is improved because the 
Managed < tejeci Ibolka takes theGDMt j ASt II file and 
automatically converts the GDMt ) specification Into an 
OSl-conformant, executable agent Tin- Managed < object 
tbolkit is described in the article on page 

TMN Applications and HP OpenVlew 

IIP t *prnVn j tt products ha\e been adopted bj manj promi- 
nent equipment manufacturers and telecommunications 
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service providers to implement a variety of TMN solutions. 
Sonu of the areas in which T.\l\ applications can be built 
upon the IIP ( JpcnView foundation include: 

• Services management for broadband networks including 
Synchronous Optical Network (SONET), Synchronous 

I >igit.al Hierarchy (SDH). Asynchronous Transfer Mode 
(ATM J. and residential sendees such as video-on-demand 

• Provisioning and monitoring applications for broadband 
networks 

• Network monitoring for outsourced customer networks 
managed by telecommunications sendee providers 

• Customer gateways into public networks Tor real-time moni- 
toring and data management 

• Integration with other management platforms for TMN cone 
pat ihi lily and a single view from a n ml ti vendor environ ment 

• Element management systems for new equipment and new 
data communications seniees. 

The IIP Open View DM platform has Traditionally supported 
the OSI systems management model to provide TMN solu- 
tions. However, in recent years the Common Object Request 
Broker Architecture (CORBA) 7 from the Object Management 
Group (QMS) has attracted interest as a general model for 
distributed application development . 

The combination of the CORBA a: id OSI models is an ex- 
tremely powerful solution for TMN application development. 
Thus t HP Open View DM platform development is moving in 
dial direct i oil 

The rest of this article will discuss various aspects ol 'the 
TMN architecture and the OSI model and dieir relationship 
to the existing OSI-based HP Open View DM platform and 
the evolving CORBA-based platform. 

TMN Architecture 

Pig. 2 shows the business, sen ice, network, and element 
management layers of the TMN model and the interaction 
between applications in these different management layers. 
Tire functionality of application in each of these layers is 
defined in ITU-T Reconuneiidal ion M^Oltl 1 

Network Element Layer Functionality at this layer is provided 
by l lie network elements (e.g., switches, multiplexers, 
repeaters, hubs, terminals, etc.). These functions include 
operations such as performance data collection, alarm 
collection, protocol conversion, and so on. Applications at 
this level are responsible for managing network elements. 

Element Management Layer Functions at this layer are respon- 
sible for managing a sithsei < >] network elements, performing 
as a gateway to network elements in the upper layers, and 
keeping statistical and historical information about Fretwork 
elements. 

Network Management Layer. Network management functions 
are used to support TMN applications that require a global 
view of the network. Data for this global view is c< illecled 
from data summarized by the network element management 
layer. This layer is also responsible for the te cluneal provi- 
sion of seniees requested by the senice management layer. 

Service Management Layer This layer is responsible for man- 
aging the seniees provided to customers. It provides the 
point of contact with customers for all service transactions, 



including billing, tjualiiy-of-senice (QoS) data, senice con- 
tracts, and so on. 

Business Management Layer. This layer contains functions 
that arc responsible for the whole enterprise. These func- 
tions include goal setting and budgeting, product planning 
and definitions, and agreements between jurisdictions. 

Operation Systems and the Manager/Agent ModeL The opera- 
tions systems shown in Pig. 2 are integrated telecommunica- 
tion management applications thai implement the network 
management fund if his in the TMN layers. The operations 
systems are based on an agent/manager model. This model 
resembles the client/server paradigm in which applications 
in the manager role are clients and applications acting as 
agents would be servers. The agent/manager model is also 
called a managed system (agent) and managing system 
(manager) architecture in TMN Lenrunology. The agent/mar v 
ager model is based on using objects to model the system 
being managed. Each object can have attributes that repre- 
sent its state or relationship with other objects, its special- 
ized behaviors (called act it jus), and notifications it issues to 
signal some event. Tims, an object encompasses a devices 
behavior as well as its physical characteristics. An agent 
resides in an object and reports the object's status to the 
manager. The manager, equipped with the capability to 
have a global view of the network, mat rages the agents and 
handles the notifications from agents. 

Q3 Interfaces. Operations systems within and between TMN 
layers are required to use a set of standard interfaces called 
Q,J Interfaces for the exchange of management informa- 
tion, 8 SJ Q3 interfaces are responsible for connecting an op- 
erations system to a network element, an operations system 
lo a Q adapter, an operations system to a mediation device. 
or two operations systems in the same TMN, Q3 specifica- 
tions use the Common Management Information Service 
Element (CMISE) protocol' for management and the file 
transfer access and management (ftamj protocol for hulk 
transfer. 

The standard way to convert anon-TMN function into a TMN 
function is called a Q adapter. Loosely staled, adaption 
is a translation between Q3 and the non-Q3 models at nut 
time. Translation to a level less than Q3 requires a mediation 
device to raise the adaption to Q'S levels. The X reference 
points in Fig. 2 also perform an interface function. They pro- 
vide an interface for cornmimications with operations sys- 
tems belonging to other TMNs or between TMN operations 
systems and non-TMN operations systems on other TMNs 
that support TMN -I ike interfaces. Q3 interfaces are generally 
regarded as appropriate for the X reference point. 

The HP OpmView DM platform supports the APIs turd proto- 
cols necessary for TMN applications. The HP Open View DM 
platform provides the Q3 interfaces via the X/Open manage- 
ment XOM/XMP APIs and the C++ classes generated by the 
Managed Object Toolkit described in the article on page §& 
Faster APIs like the BER ( Basic Encoding Rules) Manage- 
ment Protocol (BMP) and the generic data type dictionary 
APIs are available on the platform, 11 Application developers 
can build OSI applications using the APIs or the Managed 
Object Toolkit. The Managed Object Toolkit generates a 
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complete application skeleton that can be customised by 
adding user-defined behaviors. 

The OSl Model 

a* mentioned earlier TMN is based on foe c isi mode! and the 
HP r toenView DM platform supports tbe i >SJ model to < >si 

■.. m management IHSnaged oh.|.vl rbsses :m- deimed 
e^MG0MO(Gllidafae8 for the Definition of Managed 
t «rfects) A managed object class has its state and relation- 
ships wnhothe. nbjeets rr|.rv*enUHi inirs attribute*, whirl. 
, ;[]ll ,,|hvGFT ; .iulSFTiue.[K>ds,Thetn;i.uLi.,l 



,-TMN eten 

Cyyed Class definition rat, have romple* interfaces caHfid 

m and can specify noTificaiioii*. which art- emitted 
Signal r\rn1>assuriali'(l vviih ihc object. 

\lmtni. ■! Svntax Notaiion One (ASN.I i. 1 - a data definition 
language, is iisedlmh-nihr-lhe syntax ul management dala 
^changed between olyects. Behavior teniplates are used to 
dilute the semantics Of up. rai imis on attributes and ohjer^ 
and an- « nmiiHH.K capped in natural tankages. As a 
resull iheie is no standard way of parsing the behavior 
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templates. The agom developer is allows J to implement the 
\ h haviors appropriately. 

A managed ohje<i t an be created &x deleted by external 
commands if allowed by die object's GDMO *peeii'ieainm, 
ODMO allows multiple Inheritance, in which a given oluVel 
eau inherit all the operations, uolifieations, and behaviors of 
other objects, IMerenees 13, 14, and 15 provide many ofl.he 
widely used objects, attributes, and notificaiions used in 
network management. 

When defining new objects, these standard definitions are 
expected to be reused whenever possible, this is one of 
the challenging aspects of OS! object modeling. The GDMO 
Modeling Toolset, available on die IIP OpenView DM piri- 
form, makes this task much easier. The article on page 13 
describes the GDMO Modeling Toolset. 

Management Interactions 

Fig, 3 shows t he seven-layer OSI reference model. 2 Each 
layer has a clearly defined role in Hie Inuisfer of information 
over a net work. For systems management, the application 
layer is of the greatest interest Applications interopernu 
with each other using application service elements (ASKs j. 
which are defined by the application layer. The Common 
Management Information Service Element (CMISE), the 
Remote Operations Service Element (ROSE), and the Asso- 
ciation ( ontrol Service Element f AC'SE ) are ihc most impor- 
tant ASEs used for systems management. The protocols 
used to implement these service elements are also defined 
as pail Of the ISO standard specifications. 



OSl systems inanagemenl operates like the agent/manager 
model described above An application issuing management 
1 rations and receiving noli licat ions is said to be acting in 
die manager role, and an application performing management 
operations and emitting notifications on behalf of managed 
objects is said to be acting in the agent: role. An open syslem 
is made up of managed objects and the various processes 
involved in processing and transferring information. 

A manager is expected io establish art association with an 
agent using the ACSE before attempting any management 
interaction. If the association goes down, both parties can 
deieci it When the association is set up, the manager and 
I he agent exchange inanagemenl mlnrinnlion about their 
respective capabilities, including authemi cai ion schemes, 
encoding schemes, maximum data sizes, mulliple objecl 
selection capabilities, and so on. These capabilities are 
en lied functional nmis, The IIP OpenView DM platform sup- 
ports both direct user cum ml owr association management 
and the automatic connection inanagemenl mode in which 
the user does nol have to be directly involved in the associa- 
tion management. 

< nice the association is set up between a manager and an 
agent, management information can be exchanged. The 
manager is allowed to perform CREATE, DELETE, and ACTION 
operations on (he managed objects and GET and SET opera- 
tions on their attributes as defined in Iheir GDMO specifica- 
tion. Theagenl performs the operations on (he managed 
objects on behalf of Hie manager and sends replies back to 
the manager. 
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The managed object* emit notiflcations (events specified in 
their GDW » 3peciJtealioii& Not^catlorei usually signify 
sometiung Of interest happening at the ottject, like its cre- 
ation deletion, <>r attribute value change The agents deliver 
the notifications either directly to the manager or iiitlireetly 
through event forwarding discriminators, which art- matt 

itter events coming from agents, Tins fBteriog 
res That only events of i d h\ the man- 

ager : View DM platform 

the ii< ttt discrimination available 

Another important aspen i <m management is thai 

it is based on aai asynchron kg model, as 

are most other network management protocols in u 
All operations can be classified into four primitives (or 
types); requests, replies, confirms, and indicates. These primitives 
are ased in the following way: 

! To perform an operation, a manager sends a request 
message, 

2. When the message shows up ai the agent, il is received as 
an indicate message. 

:{. Later, the agertl may send a reply message. 

I. Tlu* reply message is received aT the manager as a confirm 
messa$ 

The agent sends a repJy message if the original request re~ 
quired a confinnatkm The OMSK get.cancel-GH; create. 
and DELETE operations are always confirmed, whereas die 



SET, EVENT- PtEPOST, and ACTION op« m either be con- 

firmed or unconfirmed. Request and reply messages are alv- 
directed outward from tin application and indicate and confirm 
messages are always directed in ward, 

The Open Protocol Interface Architecture 

I shows 'he IIP < JpenWw dm postmaster with the 
ted API stacks, pn ttocol rmediate 

stack master is at the hea 

I HP i rpenView DM platform. Applications bind to the 
I nasi er p e I mning on dif \ I lea P< »st mas- 

ters on i :i . t nodes coordinate interactions betwi * i i 

app 1 icalions bo 1 1 1 1 1 i t m 1 1 tern, 

The HIM ipenView DM postmaster is buili on an architecture 
known as the < Jpen Protocol Interface, which is based on 
® messaging model described above. 

Messages fl«>\s into (fee postmaster either through the API 
ks or throughUte protocol stacks, the processed mes- 
sages thai are seal oul and need euiifinuatioiis are kept on a 
sent queue awaiting confirmations. When the confirm mes- 
sages come in they are matched with the corresponding 
reqm-sl i I'his si ore-and- forward mechanism 

allows greater reliability in the message delivery, Flow 
control mechanisms are Implemented to address < congestion 
problems. 

The X/Open management \i J i> | X* M -XMPi -m-l the BEK 
Kaiiagemenil Protdeol > BMP) are Hie API stacks. These and 
ihe< MD? f SNMP(fiFG U57),andKFl L006 protocols are 
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Glossary 



This glossary contains definitions of some of the telecommunication 

terminology and acronyms used m many of the telecommunications 
articles in thrs issue. 

ACSE (Association Control Service Element) In the OSI model this 
is an application-layer protocol that is used io establish and terminate 
an association between applications on the same system or on different 
systems. 

Agent/Manager Model This model defines the basic architecture for 
network management of distributed systems. (This model is also called 
the managed system/managing system model ) The agent/manager 
system manages devices called managed objects* whtch represent a 
conceptual view of network resources that need to be monitored or con- 
trolled. The manager's role is to maintain a global view of the network 
and to control, coordinate, and monitor network activity. The manager 
also issues requests for operations to be performed by the agent and 
then receives notifications emitted by the managed objects and sent by 
the agent. The agent's role is to maintain its portion of the MI8 r receive 
and execute requests sent from the manager, and send notifications to 
the manager when necessary (see Fig. 1). 

ASN.1 [Abstract Syntax Notation One, or ITU standard X.208|< 

This is a description language used to define the data types exchanged 
between systems. 

BER [Basic Encoding Rules). A method for encoding data in the OSI 

environment. 

CMIP (Common Management Interface Protocol). This is haft ol the 

QSIs systems management protocol (the other half is CMfS). CMIP uses 
the agent/manager paradigm to communicate management information 



between systems. This protocol differs from SNMP fn that it is more 
rigorous, is designed for open systems, and is an association-oriented 
protocol, requiring the two communicating CMIP processes to estabEish 
an association before sending any management messages, This associa- 
tion is governed by ROSE and ACSE. See the article on page 52 for more 
about CMIP 

CMIS (Common Management Information Service). This is the part 
of the DSI systems management protocol that enables management 
applications to communicate in the OSI environment CMIS offers a set 
of services That provide for management operation, retrieval of informa- 
tion, and notification of network events [see also CMIP), See the article 
on page 52 for more about CMIS. 

Containment. In an object-oriented hierarchy, containment defines the 
relationship between a parent object and a chitd object- 
Contracts. In the context of the Distributed Processing Environment (DPE), 
contracts are the way in which objects in one building block (a software 
package containing several objects) describe their interfaces to objects 
in other building blocks See the article on page 17 for more about con- 
tracts and DPE. 

CORBA (Common Object Request Broker Architecture). This is an 
implementation of the Object Management Group's specification of an 
abject request broker. An object request broker provides the services that 
enable objects to make and receive requests and responses m an object- 
oriented distributed environment. 

Distributed Processing Environment This is a platform for managing 
and controlling distributed computing in a TWIN network 
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Fig. 1. The agert/manager model. 



all supported by the OSI-based IIP OpenView DM platform. 
This support along with the requirements of association 
control and routing, provide the full complement of OSI 
conformance. 

User-defined API stacks and protocol stacks can be added 
easily to the HP OpenView DM platform using the Open Pro- 
tocol Interface architecture. \>w API and protocol Stacks 
continue to be added by IIP OpenView DM users. This flexi- 
bility allows easy Integration of existing legacy applications 
inio the management framework. 



The intermediate stacks on the OS3 -based HP OpenView DM 
platform are used I o set up associations, determine routes, 
perform event forwarding discrimination, and so on. Each 
message is passed through its configured set of intermediate 
stacks for processing. 

Hie intermediate stacks can also be used for data concentra- 
tion or other similar purposes. This makes the Open Proto- 
col Interface architecture ideal for building TMN mediation 
devices, For instance, the Event Correlation Service stack 
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GDMO (Guidelines for the Definition of Managed Objects i. 

ects and their behavior are specified 
For example, GDMO can be used to specify how a certain system com- 
mand (software . d behave when executed See the article on 
page 43 for more about. GDMO. 

Managed Object wewofaloc .steal 

resource that needs to be monitored and controlled to avoid network 
failure and performance degradation A managed object is defined in 
terms of rts attributes, operations that can be performed on it. mrtfl 
tmns it may emit, and tte relationship with other objects. 

MIB (Management Information Base). This is a Structured collection 

of managed object instances and their attributes. See the article on 
page 62 for more about the MIS. 

Mediation Device. This element of the TMN architecture is responsible 
for protocol conversion, information conversion and storage, data buffer- 
ing, and filtering This is probably the most vaguely defined element m 
TMN and its functions are sometimes implemented in a Q adapter 

Network Elements |NE) + These elements represent the devices that 
make up a telecommunications network. It is assumed that an NE is 
"intelligent" enough to have the possibility of generating and transmit- 
ting some kind of information useful for network management (alarms, 
status, etc). All NEs produce for external use some sort of internal 
alarms, both urgent and nonurgent These alarms are representative of 
interna] faults Urgent alarms indicate a need for immediate mainte- 
nance. Network elements play the role of managed objects in the agent/ 
manager model. The article on page 6 contains more about network 
■ 

OAM&P (Operation, Administration, Maintenance, and Provision- 
ing), These are the functions required to solve the complex problem of 
providing telecommunications network management. 

OMG {Object Management Group). This is a nonprofit international 

corporation made up of a team of dedicated computet industry pttifes 
als from different corporations working on the development of industry 
guidelines and object management specifications to provide a common 
framework for distributed application development. 

Operations Systems (OS)* These are the applications where network 
management takes ptace They can be thought of as supervisory or con- 
trol systems that receive a large amount of data from the network and 
provide for its elaboration and for the generation of data useful for n 
agement purposes.The article on page 6 contains more about opera- 
systems 



Q Adapter This is a TMH element that rs used to connect a TMN sys- 
to a noreTMN sYstem.The article on page 6 contains more about Q 
adapters, 

03 Interfaces, These are a set of mtt thin and between 

layers in the TMN arc nge manac iration 03 

ices are responsible for connecting an operations system to a 
work element an operations system to a Q-adapter. an operations sys- 
tem to a mediation device, or two operations systems in the same TMN. 
The article on page 6 contains more about 03 interfaces 

ROSE (Remote Operation Service Element), This js a generic OS! 

ke request and reply interactions 
with applications on remote systems The article on page 8 contains 
more about ROSE 

SNMP (Simple Network Management Protocol). This is ~CF IP 
protocol that defines how to manage a network SNMP uses the agi 

manager model to monitor and administer the network. SNMP is based 
oo a connectionless protocol which requires no established connection 
between manager and agent before transmission. 

Trader Service. This is a matchmaking service for clients and servers in 

a Distributed Processing Environment A server registers its capabi I 
in the form of a contract with an entity called a trader, and when a client 
needs a ca pa bi I i ty i n a certa i n con trac 1 1 -^s The trader se rv ic a 

to find the server that has the particular capability. See the article on 
page 17 for more 

Telecommunications Management Network (TMN). TMN, which is 
defined in ITU-T Recommendation M.3D10, is a management commu- 
nications concept that defines the relationships between basic netwnik 
building blocks (nEtwork elements, different network protocols, and 
operations systems] in terms of standard interfaces. See the article on 
page 6 for more about TMN 

XMP (X/Dpen Management Protocol).This protocol provides the TMN 
I > language interface to the under lyiruj 

CMIS/CMIP and SNMP protocol services XMP APIs use XOM objects as 
parameters. See the article on page 52 for more 

XOM IX/Open OSI Abstract Data Manipulation) A C language inter- 
face designed far use with application-s; that provide OSI 
services, such as X400 and CM IS XOM APIs provide functions for 
accessing managed objects and shield programmers from the complex, i- 

if the ASM 1 data types in the MIB. See the article on page 52 for 
more, 



on the postmaster performs even! eorrehiiion for events that 
pass ilituugh the stack 

Adding intermediate stacks is relatively trivial This allows 
extreme flexibility in customizing the platform for specific 
needs Consider, toy Instance, how user-dHimd security 
might be added '<> the platform. The < >pen Protocol Intei 
architecture presently allows security information (authenti- 
cation token and authorization Main) i<> be specified In each 
message, Today such information is regarded as np;ii]iii> ;in,i 
i- m i interpreted by the stacks. If a usear-defined intermedi 
an security -.lark were added to the platform, the security 
information in the messages could he Intercepted The usei 



siatk could interpret the iitfnnnniion and accept <»r rejeer 
the message, implementing user-specific behaviors. 

Tiif i i[nw Protocol Enterface development kit is separate^ 

available as an III' produrl. 

Naming and Containment 

To perform the operations and actions described above, 

there has m be a way of addressing the objeel instances. In 
i jsi system management, each objeel instance has to have a 
unique name, known as the object's distinguished name. 
'I hr uniqueness ofthe name is guaranteed bj naming all 
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objects wiili ($spee? to a corttaitticg objecl oritsparem ta 
stance, The only (virtual) nhject not contained in aitot&er 
is railed the mot. The relationship between llie parent 
(superior) object and the child (subordinate) object is called 
containment 

Since every object instance (except ront ) is contained in its 
parent instance, an acyclic, hierarchical treeofobjeci in- 
stances can be constructed. This is known as a coTit&inment 
five. The idea of collecting objects based on containment is 

particularly use in I in defining operations thai apply to multi- 
ple objects. Such Operations arc called scoped operations in 
OSI systems management terminology, The CM1SE GET, SET. 
DELETE, and ACTION operations cam he scoprd and rvsull in 

the operations being applied to all objects that fall within 

the specified scope. Multiple object selection and actions 
make I he OSI system management model Ear more pcnwi Inl 
(and complex) than simpler models like SNMP. 

The object instance name is required in all OMTSE trans- 
actions. When autojuutir connection management is used, 
the IIP Open View DM postmaster uses a service called tin- 
uhji t ■■/ registration service to identify the target application 
for each request from its instance name. The object registra- 
tion service allows users to configure the object location 
externally, enabling one to build highly scalable systems thai 
provide complete location transparency. 

Naming and Containment are described in more detail in the 
article on page 52. 

CORES A-Based Application Development 

So Tar, we have gone over the standards support and other 
feature Of the QSI-baseri HP OpenYirw I >M Platform. Since 
mnst telecojmuunication resources today are modeled using 
a GDMO specified object, tiiese applications tend to he in 
the element management layer of the Telecommunications 
Manage men I N e I wo rk . 

As we move up the TMN hierarchy (Fig. I), the need fffl 
greater distribution, reliability database access. and user 
interface access become obvious. TMN standards do not 



constrain the internal structure ol applications. Asa result 
several nonstandard models are in use that need t<» be into 
-,i,:i' d inl< 1 a single model to reduce costa 

The new HP Open View telecom management platform 
addresses these specific issues with the use of the Common 
1 'i j. < t Request Broker Architecture (TORBA) from the 

Object Management Group (OMG), CORBA provide 
highly scalable distributed object model. TheOMG has a 
large industry participation and addresses all aspects of 
object modeling, 

I in j tew IIP Open View telecommunication management 
platform uses the IIP ORBPlus distribution backplane for 
application interactions- HP OEBPlus supports the standard 

1 1 1 H ' and J M 'K OOP transports as well as a highiy optimized 
local procedure call mechanism. 

The OMG Common ( Jbjecl Service Specifications ((OSS \ ' 
define a basic event sen ire. Even though this sei viee is mi 
plemented on the HI 'Open View platform, it is not sufficiently 
robust for telecommunications management applications. 
IIP Open View, therefore, has developed a CORBA-based 
notification service.- which allows users to register with 
a notification manager fot events filterable on multiple 
attributes. 

The CORB.Vhased IIP OpenView T telecom platform also 
comes with the ( )\\( 1 naming and life cycle services, the 
OMG standard transaction service, and a location service, 
called the trader $0&$ee. The collection of CORBA compo- 
nents and services, known as the IIP OpenView distributed 
object iiifrastrnrrnre, is shown in Fig. 5. 

The notifii niion service for the distributed object infrastruc- 
ture provides the same value in the C< )RBA-bnsed platform 
as the OSI event -forwarding discriminator does in the ( )S|- 
l >ased p I atform ; Th e eve ra> forward in g discriminators imple- 
mented on the HP Open View DM platform are more suitable 
for Q'J notifications. 
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The OORBA-based Open View \ rial U >rm also provides a m »re 
scalable version of the relationship service known as the 

iJogy service and a database strategy based on the Indus- 
try standard ( iDB « >peii Database ronneettviiv i interfaces. 
The topology service enables the develop* r n» define rela- 
tionships I i ipological entities, which are the at> 
stra i esponding to the elements in a net wo r k . 
The <■ I 'M* interface is a transparency lav 

iluim del -lationai 

- This API all- of independence frorn 

ilr databases, with a trivia] performance loss. 

With rhe availability of a CORBA-based platform, applies 
development is made conslrJ OhjBd modeling 



is done in IDL, the -e Definition Languag e. IDL 

has the same capabilities as GDMO and ASH. 1 combined - 1 
Also, the 001 rased platform allows operations on 

st as easy as operations on local 
objects, although loeal object access would be faster. 

In the model shown in Fig. 6, (X JRBA-based applications 
arid othei isiii.g adapters, or HP t Ipen- 

I r\l APIs Qj ! adapters can be generic adapters that 
!>n >\ ide a < MIP interface in IDL.— adapters tha 
mappi rigs from the X/Open Joint Intenlomam Management 

■vificada; 
rru idified J 1 1 > M hit er far i 
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The.IID.Yl adapters ran lie slat if or dynamic. The static 
adapters are I mill lor specific GDMO Mnnn.uV'menl Informa- 
tion Bases ( MTBsXamJ arte expected m pffer better perform 
rtiaiu e. The dynamic adapters use the generic facilities of 
the CORBA architecture (Oil ajid DSJ J, which are more flex- 
ible than the static inHrfarrs. TheJIDM activity produces 
mappings tor CGRBA-Q3 interaction and CORBA-SNMP 
inirracliiui. The Ct )RBA-ba.sed IIP < JpenView platform will 
siipph atlaplrrs alhr die standards in tWs .in-;i Iimu- stabi- 
lized. The Open Protocol Interface architecture discussi d 
before is ideally suited for building Q3 and SNMP adapters 
to CORBA. 

Wall tin 1 use of adapters, all other object models appear to 
be CORBA objects to the application developer Applications 
use CORBA to gain distribution, standard language mappings, 
and common object sendees for portability and the topology 
services for data integration. The ODBC layer supports 
transparent access to multiple databases. In addition, a suite 
of enterprise management tools are available from other HP 
organizations that greatly enhance CORBA-hased application 
development. 

Summary 

The new HP OpenView leU-rum plal fegttl combines the power 
m! lUe CORBA model wilh the support tor 031 management 
standards. As SNMP-based management gains acceptance in 
the telecom industry the HP OpenView SN MP- based man- 
agement platform will be integrated into the above model. 

For pure Q3 access, developers today are encouraged to use 
the 0S1 -based HP OpenView DM platform. Q adapters, medi- 
ation devices, Q3 manager applications, and Q3 agents usu- 
ally found in the TMN elernenl management and network 
element layers fall into this group. 

For highly scalable distributed applications requiring trans- 
action processing, user interfaces, database access, and 
greater com ml over the quality otserviec usually found in 
the TMN network and sen ice layers, developers should use 
the CORBA-based HP OpenView telecom plat Ion u 
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Distributed Processing Environment: 
A Platform for Distributed 
Telecommunications Applications 

Vendors developing applications for a heterogeneous, distributed 
environment need to be able to build towards a platform that integrates 
all the management and control functions of distributed computing into a 
unified software architecture that allows their applications to be available 
from any point in the network regardless of the system or geographic 
location. 

by Frank Leung, Satya P. Mylavarabhata, Trong Nguyen, and Frank Queimula 



The UV Distributed Processing Environment (DPE) provides 
iunasnueiure services (hat facilitate I he rapid development, 
deployment ami management • >]iii^in hi iied applications in 
the te]i< ommunicalions arena, DPE is a key component of 
r I m ■ Teli-cniniminicaUons [nformarjon Networking Architec- 
ture f TINA), an architecture for multimedia networks that 
emphasizes distribution and interoperability of telecommu- 
nications applications, TINA is an evolving architecture arid 
i- governed by the TINA Consort i urn (TINA ( ^ which i 
project sponsored hy 40 leading teleeomnmnicat ions and 
Computing companies. The projects aim is To fin<l a way to 
integrate all leleeominunji at ions management aiul control 
functions into a unified logical software architecture sup- 
ported hy a single distributed computing platform. 

Tins paper describes the architecture and components thai 
make up III' DPE, a product that is compatible with 
will evolve with) the TINA sp»-rificatioas. 



of several Objects and can be installed and modified inde- 
I'lrnlriuk ni of her building blocks to the network Building 
blocks interact with one another via interfaces called 
contracts. Contracts are the exposed interfaces of an ohjert 
in that they an rsed for o >: umunication between building 
blocks, They are also backward compatible to ensure inter- 
operabiiity between software objects contained in nuiltiven- 
di.r building blocks. Contracts arc subject to authentication 
and access control checks. 

A building block can be a server or a client or both. A server 
must offer one or more emmacts to allow clients to Interfax ■ 

TMN Layers 
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IN A. TINA, and DPE 

HP DPE and TINA have a common root in the Information 
N't -i working Architecture i INAj, which was 01 initially devel- 
oped al BeHcore TINAs architecture specifies a distributed 
processing environment based on the original INA DPE 
specifications. IIP DPE provides key infrastructure services 
for INA and TIN \ 

INA defines a methodology and framework tot developing, 

providing, and maintaining highly distributed systems, char- 
acteristic of i he next generation iTeumnmnieatiuns environ- 
ments. INA leverages and combines the efforts of multiple 
standards bodies, research organizations, development 

uii/ations, and consortia (eg TMN. < *S* A. OSF/DCE, 
OMG CORBA, OSIAMK etc.). Fig, l shows the relationship 
between INA DPE and the TMN (Telecommunications Man- 
agement Network) model TMN is described in the article 
on page 6 Slid the DPE services are described later in this 

INA applications and services are deployed as software 
modules mlled hnihiitiff hl<>fks, A building block is made up 
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and make use of its services, In rlu j I)PK architecture [ de- 
scribed below), applications are modeled as bmlding blocks, 
The DPE itself is made up of server building blocks (e.g rT 
contract trader, repository; etc. ) which offer contract inter- 
faces to application client building blocks. 

The IN A structure enables distributed software building 
blocks from multiple suppliers to interoperate. This distrib- 
uted object computing results in faster software develop- 
ment since there is greater software reuse and modularity in 
design. 

In summary, IN A is a framework for interoperability porta- 
bility, and network resource management. The following 
goals have been established for IMA: 

• Rapid and flexible introduction of new services 

• Reuse of software modules 

• Use of general -purpose solutions 

• Mulf.ivendor hardware and software solutions 

• Independence of applications from die transport implemen- 
tation technology 

• Separate transport technologies from higher-level control 
an d O AM & P { ope ra I i 01 i , at lm i ni sr ration , maintenance , and 
provisioning) 

• Allowance of Customer access to OAM&P sendees 

• Seamless integration of services 

• Network and element management . 

DPE Architecture 

Fig. 2 shows the components and services that make up the 
DPE architecture. 

DPE Kernel. The DPE kernel provides the foundation for 
building block interaction and execution services. To imple- 
ment these services, the DPE kernel uses the services pro- 
vider! by the underlying native computing and communica- 
tions environment, which include: 

• DCE: threads, security, RPC. and IDL compiler 

• COKBA: IIP ( WB+ with DO and DCE CIO protocols and 
( -IDL compiler 



• IIP Open View components; XMF API, pmd (postmaster dae- 
mon), orsd (object registration service), and ovead daemon 
{event sieve agent). 

The DPE kernel is resident in every node of a distributed 
system. Building blocks and other DPE components at a 
node cannot access the DPE kernel at other nodes directly. 
Access to the DPE kernel services at a remote node is ac- 
compli shed using the interprocess communication facilities 
of the native computing environment of the node. 

Contract Adapter. A con tract: adapter is ait application pro- 
gramming interlace that provides all the transparencies re- 
quired by a client or server building block. It also provides 
an API for accessing either application-level services or ser- 
vices provided by DPE. Contract adapters are kept as library 
modules which can be linked with building h locks before or 
during execution. 

The inclusion of adapters as components of DPE implies 
that the components of DPE increase over time as new ap- 
plications are deployed iit a network, When a contract type 
is specified and registered Tot sum e application-level service, 
adapters for rhe.se contract types can be automatically gen- 
erated and marie a pan of I )PE 

DPE Services. Each DPE service is a building block and 
access to its functions is only through contracts offered by 
I he DPE service. A node may have zero or more DPE ser- 
vices installed, Since access to a function provided by a DPE 
service is available only through a con tract, a building block 
or a DPE service in a node can use the functions provided by 
a DPE service in a remote node. Thus, DPE services depend 
on the communication and execution services provided by 
the DPE kernel. References to contracts of some of the DPE 
services, such as the trader, can be passed to a building 
block when it is activated. 

Although both DPE services and appli cations are built using 
the concepts of building blocks and contracts, there is a fun- 
damental difference between the I wo. DPE services do not 
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architecture, 



18 October 1JMJ Hewlett -P;i. -kard JrmmaJ 



)Copr. 1949-1998 Hewlett-Packard Co. 



provide network resource management functions, nor do 
they provide telecommunications services to network cus- 
tomers. These functions are provided only by applications. 

Fig, 3 shows die interactions among trie DPE services shown 
in Fig. 2. An arrow directed from one service to another 
indicates thai the source service pn I he 

destination service. 

Contract Trader, This DPE service provides a cita 
U ir client and server huildinu bfdcics Et is 
providing location transparency in a distributed network 
When a building block offers a contract, information about 
this contract is conveyed to the DPE kernel. This infomia- 
tion iiuimit ss tlv name of the correspono^g contra" 
and tlit- \ ahie of the service attributes provided by the 
contract DPE stores this information in the repository 1 . 

When a client wishes ti > invoke an operation defined in a 
specified contract rype. it queries the DPE trader fortius or 
more references to Contracts that mat eh the specified type 
and whose service attribute values satisfy a constraint 
expression supplied by the client Regardless of where the 
server is physically located, the cheiti can discover servers 
at run time, based on the latest contract information re- 
corded in the repository database. The DPE trader provides 
two types of contract trading: attribute-based trading and 
resource-based trading. 

The attribute-based form of contort discover is based on 
the specified contrail type and a constraint expression in- 
volving any number of the service attributes. Hie constraint 
expression used by HP DPE is modeled after l lie ANSAware 
2.(1 const rain! language. This language supports relational 
operators OJft attributes and maximum, minimum, and logira] 
operators. This provides a groat deal of flexibility in how a 
client discovers a server, 

An example of a constraint expression might he a request to 
find one or more print servers thai can prim In color, provide 

A4 size paper, and use PostScript 7 '* fonts. The constraint 
language would express this request as: attribute J ist - color, A4 H 
postscript. If we need a certain capacity and speed fpi the 
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printer, we might add a request for faster than six pag« s 
minute: attribute, list > 6. 

A resource-based form of contract discovery is an 
of attribute-based trading and is used by resource manage- 
ment applications In resource management applications, it 
is typical to provide service over a domain of resources. This 
domain may be dynamic. An example would he a connection 
management applicati on t hat i si i r p n m < i 

connection management s* g 

numbers i domai 1 1 ) hegii i vvUIi area c md have the 

exchange mun he i applicatton may ofler cooO 

a domain that may van m size depending on how many 
,e numbers aie actually assigned (e.g.. all the numb 
following 447). This type of trading requires the dm 
supply a contrsu I type name, a constraint expression, and 
the name of the resource. With this information the HP DPK 
trader can locate a seiwr offering a contract offcta 
prune type thai satisfies not only rht j search constrainl ex- 
pression, but also the Specified resources. 

Repository Server. This I >J'K service maintains persistent in- 
iormniioii for I he operation of DPE. It Stores specifications 
of trading attributes, contracts, building blocks, and configu- 
ration information. Tlie repository server pn>\ ides operations 
for the creation, retrieval, update, ami withdrawal of DPE- 
l>oisistenf objects. These reference objects are used to initial- 
ize, activate, deactivate, and withdraw contract and building 
block instances using a generic front -end administrative 
tool. This server is implemented using the ObjectStore 4.0 
(>( )DBMS from Object Design Inc. 

The information stored in the repository can be used for 
several purposes. The DPE front end can traverse repository 7 
information to help application developers locate potential 
reusable attribute types, contract types, and huikling-bloi k 
type specifications. It also provides type information that 
allows the DPR (out roller to check for valid operation 
parameter types ai run tune. The following three kinds of 
information are stored in the repository, 
Specification information. This consists of information con- 
tained in contract type specification templates and building 
block type speeiGcation templates registered v\ tfch the I >PE 

i epos m 

Configuration information This consists of Information con- 
tained in the buUding-block configuration templates, contract 
configuration templates) and node configuration templates 

-j ci id widi the DPE repository. This means that the re 
posit ory contains information needed for managing building 
block instantiating operations or startup operations 
Trading information. This consists of information that sup- 
ports trading operations, specifically contract types :imi 
contract instances, 

Registrar. This DTK service provides registration and with 
drawn I services for the various templates Bsed in the oper 
ability services, including specify at ion templates, installation 
templates, and configuration templates* its function is to 
i mi si and i crdy the correctness of tin- specification tem- 
plates before invoking the registration operation of the 
repository server, 
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Fig, 4, The DPE graphical user interface. 

Node Controller. The node controller at each node provides 
activation, deactivation , monitor, and restart functions tor 
building blocks configured in that node. Ft receives notifica- 
tions when a building block is started and deactivated, and 
continuously monitors the "liveness" of all building blocks 
executing in the node. Since the implementation of these 
functions is dependent on the native computing environ- 
ment's faculties, one instance of the node controller building 
block is required in each node. 

Management Front End. HP DPE provides a graphical front 
end and a command line interface to DPE system adminis- 
tration, building- block management, repository browser 
functionality, and DPE shutdown and restart functions. This 
user interface offers a generic and uniform way of managing 
the whole DPE domain from any node. DPE objects present 
in the GUI are organized in a hierarchical structure similar to 
the renowned Smalltalk browser. This structure is organized 
as nodes, building block types and instances, and contract 
types and instances (see Fig. 4). The DPE front-end inter- 
face provides the following functions: 

• Contract building-block type registration 

• Activation, shutdown, and withdrawal of building-block 
instances 

• Activation, shutdown, and withdrawal of contract instances 

• Setup and modification of contract trading attributes 

• Browser for DPE objects. 

With the command line interface, routine DPE administra- 
tive tasks can be automated using shell script languages. 



DPE Telecommunications Examples 

This section provides two examples of the use of IIP DPE in 
the design and deployment of telecommunications services 
and applications. The steps illustrated in these examples 
present a high-level view of the communications that, occur. 
The actual designs are much more complex. Also, to reduce 
the complexity of the figures, three assumptions have been 
made: 

* All interfaces that are used have already been registered 
with the DPE registrar, and binding informal i< m for each 
interface is available from the DPE repository. 

* All communication with the DPE trading service is done via 
an RPC mechanism. 

* Most applications will either trade at initialization time to 
obtain binding handles or simply use a well-known address 
to maximize throughput. Trading during execution will most 
likely be reserved for those occasions that dictate the need 
for dynamic binding, For illustrative purposes, however, the 
examples show trading occurring for each initial conunum- 
cation between any two modules. 

Example 1: Permanent Virtual Circuit Service 

The most basic connection service provided by broadband 
networks is a permanent virtual circuit (PVC) service. This 
service provides the capability of setting up a connection 
between two or more points with given bandwidth and 
quality-of-service (QoS) parameters. Typically PVC s are 
long-term connections used to interconnect LANs or provide 
long-term video service between distant points. Fig. 5 illus- 
trates how a simple PVC service might be designed using 
an architecture based on INA. Each of the following steps 
corresponds to a number in Fig. 5. 

1. The PVC presentation module consults with the DPE I Hid- 
ing service for the location of the PVC processing module 
applications, This communication is done via an RPC 
(remote procedure call) interface. 

2. The PVC presentation module provides the PVC processing 
module with the user inpui parameters that define the PVC 
being request ed. This communication is done via an RPC 
interface. 

3. The PVC processing module consults with the DPE trader 
to locate the connection management, application server 
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Thai controls the switch servicing the originating end of the 
PVC, Tins is done via an RFC interface, 

4 The PVC processing module uses The DPE RFC mechanism 
lo access the connection management application. If the 
connection requires more than one switch, the connection 
manager will irade for and bind to another connection man- 
ager to move the D mnection towards the termination point 
(this is jhit shown in Fig, g), 

5. The connection manager trades for the binding handle of 
the managed object agent that services the originating < and 
terminating if local ) points. For performance reasons, in 
mosl designs this Step is done at system initialization lime. 

ix The connection manager instructs the managed object 
agent to conned the originating end using the DPE system 
management protocol CMISE (Common Management Infor- 
mation Service Element ), 

7. The connection manager instructs the managed object 
agent to connect l he terminating point using the I MISE 
protocol 

8. The connection manager uses HPC to request a binding 
handle from the connection data building block 

9. The connection manager requests the connection data 
building block to i ipdat e its data store to reflect the adi 1 1 

of the new PVC connection. The communication is done via 
RPC. 

10. The connection manager reports the establishment of a 
connection back to the PVC ! processing module via an RP< \ 

11. The PVC processing module returns the Status of the 
connection establishment back to the PVC presentation 
mod ule for display ft) 1 he user. 



Example 2: Switched Virtual Circuit Service 

This example shows that the modularity and code reuse 
capal i ■ I i t > of The DPE architecture can be used to add new 
features. The switched virtual circuit implementation shown 
in Fig. 6 provides users with the capability to establish or 
reconfigure existing connection sessions at any time, much 
like voice telephony service. As shown in Fig. 6 the connec- 
tion management, data building block T and managed object 
agents are all being reused. Only the top two modules need 
to be replaced with new code. 

Suimnarv 

This paper has presented an overview of the HP DPE imple- 
mentation, DPE plays a key role within the Telecommunica- 
tions Information Networking Architecture (TINA), HP DPE 
offers a development environment to develop distribution 
transparency for both RPC-based and CMlP-based INA-com- 
pliani applications. This paper has also detailed the services 
provided by HP DPE and described the implementation of 
the contract trading servers and cniilracl adapters, lite key 
components providing distribution transparent 
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HP OEMF: Alarm Management in 
Telecommunications Networks 



This article explains the HP OpenView Element Management Framework 
concept, which is based on the HP OpenView Fault Management Platform 
(FMP) and complements the functionality of the FMP to provide an 
integrated network management solution. This article also explains the 
FMP, which facilitates efficient management of alarms in a 
telecommunications network, and the open APIs provided in the FMP f 
which allow seamless integration with other applications. 

by Sujai Hajela 



There has been an unprecedented growth in the telecommu- 
nications industry around the globe. The rapid evolution of 
new technologies, the offering of a broad spectrum of data 
services, and the need to have last access to information are 
some of the factors dial have contributed to a tremendous 
increase in the number of subscribers to telecom services, 
This lias imposed great demands on the telecommunications 
networks of holh public and private operators. To keep up 
with the demand, telecom operators are expanding their 
existing infrastructure at a hectic pace Furthermore, deregu- 
lation of the telecommunications industry has led to the 
emergence of a number of private service providers, and this 
has created keen compet.it ion within 1 he industry. A good 
quality of service at an economical price has become a key 
factor for service providers to increase their customer 
bases. 

Telecommunications Management Network 

Offering a high quality of telecom services and at the same 
time generating high revenues requires efficient management 
of feleeonununications networks by the service providers. 
The Telecommunications Management Network (TMN) 
defines activities that aid in managing a telecommunications 
network According to ITL'-T Recommendation M.3010, a 
TMN is intended to support a wide variety of management 
areas including planning, installation, operations, athnuus- 
tration, maintenance, and provisioning of te lee onununi ca- 
tions networks and services. The following live functional 
areas have been identified in TMN (ITU-T Reconunendation 
M;.U0O): 

• Fault management 

• Configuration management 

• Performance management 

* Security management 

* Accounting management 

Fig. 1 shows the TMN functional blocks and components. 
The TMN architecture consists of the functional architecture, 
the information architecture, and I he physical architecture- 
The TMN functional architecture defines the following 
blocks: 

* Operations systems function (OSF) 



• Mediation function (MDF) 

• Network element function (NEF) 

• Workstation function (WSF) 

• Q adapter function (QAF). 

The TMN information architecture defines I he information 
exchanged between these functional blocks. 
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The TMN physical architecture provides a means to trans* 
port and process information. The physical architecture is 
made up of the following types of physical components: 

• C >j «erat u >i is 53 |S). Performs OSK 
■ Mediation device i ML* i, Performs MDF. 

• Q adapter (QA). Performs QAI network 
elements and operations systems with noncompatible inter- 
faces to OSI Qx and Q3 tnterfa 

t communications network (DCN). Performs data com- 
munications function (DCF). which is used by Die TMN 
functional blocks to exchange information. 

• Network element f XEh Performs NKK 

• Workstation (WS). Performs WSF. 

OpenVlew Element Management Framework 
Tlie UP Open View Element Management Framework i ( )EMF) 
aims to provide a set of management activities defined in 
ITl -T Recommendation M.34G0 to facilitate efficient man- 
agement of a telecommunications network. The functional 
areas covered w iihin the OEMF are fault management 
(including trouble management), performance management, 
and other ihird-parry applications to complement the existing 
set of applications under the OEMF umbrella — for example, 
configuration management and asset management. 

OEMF is an open system that makes possible Ihe detection, 
isolation, and rorreciion of abnormal operation of the tele- 
comnmnieaiions network. < f£MF consists of the HP Open- 
View Fauh Management Platform (FMP) integrated with the 
Trouble Ticketing System provided by Kemed.v and the Per- 
formance Management. System from Met he a. Other third - 
party applications for inventory, asset, and configuration 
management have also been integrated Integration with 



test and measurement products like HP AcceSST further 
enhances the OEMF functionality 

Fig. 2 illustrates the physical architecture of the OEMF 
OEMF has a distributed architecture in wliich different man- 
agement activities can reside on different servers or on the 
same server. OEMF offers application availability, that is, if 
one of the management activities ceases to function, die 
operator can stiU execute the functionality provided by the 
other applications. 

In the TMN hierarchy, OEMF resides between the network 
management level and the element management level < Rg 
It can manage the network elements directly or can be inter- 
faced to an existing element manager to manage the network. 
Providing this flexibility to OEMF are a rich mediation ser- 
vice and APIs (application programming interfaces) foi 
grating with customer-specific data collection mechanisms. 

Fault Management Platform 

T!te FMP is a fault management platform that provides util- 
M \ tools for managing alarms from multi vendor devices and 
network element managers. It is based on die IIPOpetiYiew 
Distributed Management Platform, It has an extremely open 
architecture, which facilitates a seamless integration of 
third-party applications, as manifested by the Open View 
Element Management Framework described earlier Fig. 4 
illustrates the FMP functional blocks. The main components 
of the FMP are the mediation device block, the FMP server 
block, and the graphical operator interface. 
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SDH = Synchronous Digilat Hierarchy 
EMS = Element (Ufa n a g e me n t System 
QMS = Operations Man age men! System 

Fig. 3. In MirTMN hierarchy, (fee HI' i >KMI" n--i i, s I ■■■ 'v,v. f! the 
network managem'TiT Ifvel and the element management level. 

The mediation device block provides the mediation and Q 
adapter functions and the FMP server provides the opera- 
tions systems function. The mediation device logs, formate, 
filters, maps T and finally correlates all alarms it receives 
from network elements into ITU-T X.733 alarm reporting 
formal, and sends these alarms to the FMP server for alarm 
management. The mediation device can send the alarms to 
the FMP server using the CMISE protocol over the CM IP 
stack provided by the HP Open View Distributed Managemenl 
Platform, or optionally, using the CMIP-LITE protocol (an 
KMP representation of the X.733 alarm report) over TCP/IP 

The FMP server performs the problem condition manage- 
ment services. It provides graphical operator interfaces to 
aid in the management of the alarms being received from 
the network elements (which are performing the network 



element function). These graphical mterfaces provide Hm- 

means to interpret TMN information for the managemenl 
information user. They perform the workstation function, 

"['he FMP provides the fault managemenl activities in a t£)i - 
communications network. However, to manage a telecom- 
munications network, other management activities such as 
Trouble management, performance management, and config- 
uration management are also required. This requirement 
contributed to the OEMF concept, which allows a broad 
sped rum nlbesl -in-class applications, regardless of manu- 
facturer, to be integrated with FMP to provide an integrated 
network managemei 1 1 sul 1 1 r i o n . This integration is mad e 
possible by a raitge of open APIs provided in the FMP The 
HI 1 OpenView Distributed Management Platform APIs fur 
I her enhance the integration capabilities. 

Mediation Device Block 

The mediation device logs raw alarms, formats and filters 
alarms from events, correlates Ihese alarms, and then for- 
wards them to the FMP server in the X.733 alarm reporting 
format. The mediation function is extremely import an I as 
the FMP server receives and manages alarms in a heteroge- 
neous, lmtlti vendor; mulUuetwork environment in which Hie 
network elements send events in varying formats, Fig. S 
illustrates the functional blocks within the mediation device. 

The mediation device provides a set of data collectors, 
which collect data over RS-232, TCP/IP, and SNMP. Reports 
in X.733 format can be sent directly to the FMP server using 
0M1P protocol. For data collection over X,25 and other 
types of networks, customer-specific data collectors can be 
written using mediation device connection APIs, These data 
collectors forward the events to the even I logging module, 
which logs them into raw log files. The event logging module 
forwards the valid events fcp the event formatting module, 
which parses the incoming events and then classifies and 
formats I hem into message classes based on the parsing 
niles defined in the configuration. These formatted events 
are then logged into message class files cor responding to 
the message classes. The event formatting module forwards 
the events to die event mapping module, which filters the 
alarms from events, converts the alarms into the X.733 
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alarm report format and forwards them to the event Oltoriii^ 
and correlation modi lie. The correlation module correlates 
repeated alarms, transient alarms, and related alarms for a 
network element. The FMP supports a two-stage correlaii« m 
approach in which the eoj relation functionality ifl provided 
al (he mediation device and at the FMP server The correla- 
tion module forwards the alarm to the module interfacing to 
the FMP server. This module encodes the alarm into ( MIP 
and sends it over the CMP stack provided by the HP Open- 
View Distributed Management Platform or optionally (de- 
pending upon the configuration) encodes the alarm into 
CMIP-L1TH and sends ii over TCP/IP to the FMP server 

Correlation in the FMP 

The FMP allows two stages of event correlation: one at the 
mediation device level and the other at the FMP server level. 
The correlation at the FMP server is done across the network 
being managed because ti\e server has access to the topology 
i base. The correlation at the mediation device is restricted 
to the network elements to which !he medial ion device is 
connected. The correlation at the medial ion device level is 
done primarily to prevent not-so-important data from heing 
forwarded from Ihe mediation device to the FMP server. 



The FMP has two types of correlation: repeated/transient 
correlation and root -cause/re luted correlation. Repeated/ 
transient correlation correlates alarms that are identical 
(they may have different severities) and are being emitted 
continuously by a network element. Root-eause/related cor- 
relation correlates alarms that have occurred because of a 
root-cause alarm and are not as important to the operator. 

Let's take an example of root-cause/relatcd correlation in a 
GSM network- Assumptions: 
. MSOl is connected to BSC-1 which is connected to BTS-1 
through BTS-4. 

* An alarm A:MSC-i (that is, an alarm of type A:MSC at MS( ' -1 ) 
causes an alarm B:BSC-1 (an alarm of type B:8SC at BSC-1). 

* The alarm B:BSC 1 causes an alarm C:BSC-h 

* The alarm C:BSC-1 causes alarms D:BTS-h DSTS-Z, D:BTS-3, and 
D:BTS-4. 

* Of all these alarms, only A:MS01 is significant. 

Fig, 6 illustrates the scenario. Based on the above assump- 
tions, if an alarm A:MSC-1 occurs, the operator will also 
receive the alarm BBSC-1 which will further cause alarms 
C:BSC-1 and D:BTS-1 through D: BTS-4. Even though the real 
problem is with MSC-1, the operator receives numerous 
alarms, many of which are of uo signiln am v. 
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D:BTS 



BTS-1 



BTSZ 



Fig. 6. Scenario of alann generation in an ^xatfiple GSM rn I 
without rurn-'latiun. Many extraneous alarms can be generated m 
addition to the rootncause item 

Let's spe t ify the correlation rules to be as follows (the 
formal of the event correlation rules specification has been 
simplified to explain the concept); 



Rule 1; ROOTCAUSE : 


A:MSC RELATED 


B 


BSC 


Rule 2 : ROOTCAUSE : 


B:BSC RELATED 


C 


BSC 


Rule 3 : ROOTCAUSE t 


C:BSC RELATED 


D 


BTS 


Correlation window: 


20 seconds 







With these correlation rules in effect, the operator will re- 
ceive only (he aki n n A:MSC-K which is I he significant, alann. 
This behavior is illusl rated below: 

Correlation window (total elapsed time ) = 20 seconds 

I <— — — . __ > | 

I 

Arrival of A:MSC-1 ->I->A:MSC-1 sent I 

Arrival of EBSC-1 >l I 

( co rre I al et 1 I iy ru I e I ) I 

Arrival of C:BSC-T — — >l I 

(con elated by rule 2) I 

Arrival of D;BTS- 1 — — — >l I 



(all BTS correlated by rule 3) 
Arrival of D:BTS-4 



->l 



End of Correlation Window- 



->l 



All alarms matching the correlation rules and occurring 
within the correlation window are subject to correlation. 
The correlation window can be a fixed or a sliding window 
The arrival order of alarms is not important — in the above 
example, the alarms could have arrived in any order. As long 
as they arrive within the correlation time window, they gi .m 
correlated. If a related alarm arrives before a root-cause 
alann, it is held in the correlation module until the end of 
the correlation window. If the root -cause alarm does not 
arrive within the time window, the related alarm is sent out 
as unconelated. If the root -cause alann arrives before the 
related alarms, it is sent out im mediately. In the scenario 
above, the A:MSC-1 is sent out by the correlation module 
immediately and is not held back until the end of the cor- 
relation window. 

Event correlation services are available in HP Open View 
Distributed Management Platform 4.21 as an option (see 
article on page 31), Event correlation services fun tier 



complement the event correlation provided by the FMP and, 
when integrated with the RVlP, greatly enhance the correla- 
tion functionality of the KM P. 

FMP Server Block 

The FMP server provides problem management services. It 
logs, correlates, and distributes the alarms to the graphical 
operator interfaces. Fig. 7 shows the functional blocks within 
the FMP server. 

An alarm is received from the mediation device (there may 
be one or more mediation devices) either in CM IP or CMIP- 
LITE by an interfacing module, which decodes and forwards 
it to the alarm logging module. Tire alann logging module 
logs the alann in the alann database. This alarm is then 
passed to the alarm correlator module for correlation. This 
is the second stage of con-elation, the first being at (he medi- 
ation device. Correlation at the FMP server is performed 
across the network because the server has access to ilie 
topology information stored hi the topology database, which 
resides at the server. After correlation, the alarm is disti il> 
ut.ed to the alarm handling module and the network status 
monitor module. The alann handling module manages prob- 
lems I -a cry alarm need not be a new problem — many alarms 
may be sent lor I fie same problem The alarm handling mod- 
ule identifies I he alarm ;is belonging to a problem it it ot'hji 
nates from the same network element and has the same 
probable cause and specific problem lieids as the problem 
(these fields are specified by ITU-T X.733). The alarm han- 
dling module checks whether a problem condition already 
exists for the alarm received. Hit does, then an update to 
I lie problem is sent to all the connected alarm viewers. 
Otherwise, a new problem condition is created and sent to 
the alann viewers depending upon the span of control de- 
fined for each alarm viewer. 

The network status monitor is responsible for status propa- 
gation according to the configuration rules. Depending upon 
(he severity of the alann, die network status monitor calcu- 
lates and sets the status of the alarming network element on 
the network map. Tire network status monitor calculates the 
status or objects based upon the severity of objects both on 
the map and not represented on the map (mm amp objects). 
Tire need to support the concept of n on map objects arises 
because in a telecommunications environment t the number 
of objects being managed ran be very large. .Also, the opera- 
tor may prefer not to see all of the objects being managed 
on the map, but would want the status of the nomnap ob- 
jects to be considered while ealciduting the status of the 
higher-level objects (in the containment hierarchy) that are 
represented on the map. 

The stains manager' server (or simply status manager) facili- 
tates the submission of outage schedules and maintains in- 
formation regarding the outage of the network elements: 
Operators submit the outage hrfonnation through the status 
manager clients. 

Graphical Operator Interfaces 

The FMP includes a set of utility tools that provide a graphi- 
cal interface for the operator to manage the Lelecomnuinica- 
lions network. The tools provided arc 1 the alarm viewer. The 
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Fig. 7. f'MP server mn< linn at block di 



net work map application and the slams manager clients f< »r 
submitting oulnge schedul* 

Alarm Viewer. The alarm viewer is an XI l/Motif-based appli- 
cation thai allows the operator to view the faults occurring 
in the network being managed and provides facilities to lake 
corrective actions in handle these faults. Fig. 8 shows the 
alarm viewer window 

The alarm viewer receives the problem condition from the 
alarm handling module. II allows die operator to selerr and 
perform Ihe following actions on the selected problem 
condition: 

• Own 

• Disown 

• Discharge 

• Locale 

• VIew ? Problem Condition History 

• Create Trouble Ticket 

• View Details 
■ Prim, 

By owning a problem condition, the operator acknowledges 
the presence of a fault The operator can then locate die 
alarming network element on She network map and create a 



i rouble ticket for the problem. Once ihe problem has been 
rectified, il can be discharged i >n being discharged, Ihe 
problem disappears from (he alarm viewer. An audit 1 rail is 
maintained in Hie alarm tlalaba.se regarding the actions per- 
formed on die problem. A list of all the* alarms corresponding 
to die selected problem condition is displayed by clicking 
the Problem Condition History button. The alarm viewer can be 
configured to display only the fields in which the operator is 
Interested. The Details button can be clicked to view the de- 
tails of the problem condition. A hard copy of the selected 
problem condition can be obtained by selecting the print 
option. 

The alarm viewer provides visual aids for quick identification 
of I he severity of the problem. The columns in the problem 
condition row are color-coded and signify the outage, the 
severity, and the ownership status of the problem. 

An operator can invoke an alarm viewer and perform actions 
on the selected problem conditions. However, operaiors 
need to be registered wiih the FMP server, and their spans 
of control, or m&rut&emcnt dfowioittSj need to be defined 
thelf control can be defined on the basis of the nelwork 
instance, the network element class, and the network 

element instance. The alarm handler ensures I hat all the 
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alarm viewers are consistent in ease there is overlap in the 
operators' spans 0{ control (it is common to have multiple 
operator's responsible Tor the same nel work elements). For 
example, if a problem condition is owned at one alarm 
viewer, this owned sLatus is propagated to oilier alarm 
\iewers displaying this problem. 

Alarm viewer menu options allow an operator to customize 
the alarm viewer. Operators can set their own soiling crite- 
ria for problem condition display. They ran also sel their 
own view preferences, for example to view problems from a 
certain network, view problems of a certain severity, view 
problems they own, and so on. These menu options otter 
flexibility and convenience to help the operators efficiently 
manage, the problems occurring in the network. 

The alarm vi e wer allows externa] an d custom er-s pe e i fie 
applications to be registered with it, A problem condition 
can be selected and any of the registered applications can 
be invoked for the selected problem condition. This is an 
extremely useful feature which allows integration of the 
FMP with best -in-class applications from any vendor to com- 
plement the FMP functionality. 

Network Map. The network map is ait OpenView Windows 
application that displays the network being managed and 
the status of the network elements within it. The network 
elements are represented by icons and the colors of the 
icons represent their severity. The network map gets status 
updates from the network status monitor module. It allows 
the operators to navigate through the managed network and 
isolate the network elements generating the problem condi- 
tions. It also allows updating of the topology either interac- 
tively through the tnenu options provided or programat ically 
through the map loader APIs. The network map can be cus- 
tomized by creating logical views of the network. Thus, an 
operator can navigate through the whole network hierarchy 
while a manager can choose to look only at the status of the 
network at a higher level without going into the details of 
the network elements wilhiu I he network. 

The network map has the FMP registered as an application. 
The FMP menu option allows the operators to invoke various 
applications like the alarm viewer and the status manager 
clients. 

Fig. 9 shows a network submap for an example GSM net- 
work, 



Fig. 8 . y arm viewer srii idu w. 



Status Manager Client. The status manager client is an XI 1/ 
Motif application thai allows an operator to submit outage 
schedules, that is an operator can submit a proposal to put 
a in twork element out of service or restore a network ele- 
ment back into service. The operator needs to be configured 
for the status management capability to submit the outage 
schedules, The operator can specify I he stmt and end times 
of the outages and whether the network element will be 
restored manually or automatically to in-service status, II" an 
atotn is generated by a network dement that is in the outage 
state, it is flagged by a different color in the first column of 
the alarm viewer. The FMP server can also be configured 
such (hat alarms from network elements in outage status are 
nor sent to the alarm viewers at ;il[. Information regarding 
the outage status of the network elements is maintained by 
the status Mi;iii;iger si-ivvr 

FMP Configuration 

The mediation device has (o he configured to be able to re- 
ceive, format, and map events received from multivendor 
network elements in the X, 733 alarm format. The object 
model of the network being managed, the different types of 
network elements? event correlation rules, operators' spans 
of control, arid stains propagation rules all have to be con- 
figured. Information regarding the mediation devices con- 
neeted to the FMP sen er (the FMP server can he connected 
to 3 1 lore than one mediation device) and any customer- 
specific data collectors connected to the mediation devices 
also needs to be supplied. 

FMP provides a screen-based GUI utility — the configurator 
— to aid in configuring the FMP and customizing it to manage 
a heterogeneous telecommunications network, 

FMP Application Programming Interfaces 
Throughout the design of the FMP, an open architecture and 
ease of integral ion were always given maximum importance. 
The FMP allows seamless integration with ruber applications 
as a result of its rich set of C and C++ .APIs. The various APIs 
are described in the following paragraphs. 

Data-Collector-to-MerJiatioft-Device Connection APIs. These 
APIs can be used to write customer-specific data collectors 
to send events received from the network elements to the 
mediation device 1 . Apart from data collection, these data 
collectors Can also use these APIs to inform the mediation 
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Fig. 9, Network subffl 

gion pi m exampli ' iSM network 



device regarding their operational status and to gel informa- 
rimi regarding the operational status of the mediation device 

High-Level Parsing APIs. High-level parsing APIs facilitate the 
validation of events received from the network elements. 
Tin- data collectors can use these APIs to find tin* validity at' 
:m incoming event and Bag the evenl as valid or invalid. This 
information is used h> the eveiti logging module in the medi- 
ation device GO tag the event as valid Of invalid in the raw log. 

Pseudocode for a sample data collector using the data rol- 
iectorand hiuh-lrvei parsing APIs is as follows: 

main ( ) 
i 

Open the network element port 

for f ,- ; ) 



{ 



If (Data received from network element 
port) 
{ 

//High-level parse the input data 

//received 

FaultBuf = HLPParse (Data Received) 

//Send the structure returned by the 

//HLPParse to the mediation device 

DCSendFaultToMD (FaultBuf) 

1 
//Inform the mediation device if the 
//network element port is not OK 
If (Error in network element port) 

DCSendPOrtStatusToMD(Port is not OR) 



//If the mediation device is shutting 
//down, shut down this data collector 
If ( ( (msg = DCReceiveFromMD( control 

message from KD }> m MM_SHUTDOWN) 

Shut downTh is DC [ ) ; 



> 



Log APIs. The mediation device togs ran* data received from 
the network elements, Ii then classifies these events 
nies es and togs diem in the corresponding message 

class Hie. The log APIs ran he used to access these Hips. A 
number of applications can use the mediation services of 
the FMP and have the data collected ai the mediation device 
in a formal desired by them. These applications ran then 
access fins formatted information using the log Wis Many 
Interesting and useful applications ran be written using the 
mediation and togging services provided hy the FMP An 
example is a raw log hrnwser. which allows the opera I or 
to select an XJ'V-l alarm 1 1 1 >:n the alarm view er and I lien 
extract raid browse the raw alarm data corresponding to tile 
selected alarm. 

Application Registration APIs. These APIs allow Ihe resist iai ion 
of external applications with the alarm viewer and facilitate 
passing information ahoni the selected problem conditions 
to these applications. Application registration APIs ran be 
us d to integrate customepHspecific applications. < tacts regis* 
tered, the applications can be invoked hom the Applications 
menu option of the alarm viewer Taking iiu* example <>f the 
raw log browser, the browse] would first be registered with 
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tile alarm viewer. Then a problem condition i an be selected 
and the raw log browser application cad be invoked. Assum- 
ing that a raw log index is passed as some field in the X.733 
alarm (e.g., rawlogmdex as a part of additional information), 
this application can use the APIs to extract this index, which 
can be used to access the raw log. The trouble management 
sysi em provided under the OEMF also uses these APIs. 
When a problem condition is selected and a trouble ticket is 
created for it, the trouble ticketing application uses these 
A Pis lo gejt information regarding the problem condition. 

Problem Condition Management APIs, These APIs allow an ap- 
plication to interface to the problem condition management 
services. The alarm viewer uses these APIs, Customized 
alarm viewers, an automatic trouble ticketing application, 
ail automatic problem condition discharge application, ami 
Other applications can be written using these APIs, Take, for 
example, an automatic problem condition discharge applica- 
tion for managing problems for which I he switch normally 
does not send a clear event. Based on certain criteria like 
I he age of the problem condition, its severity, and so on. this 
;u -plication bail be designed to discharge the problem condi- 
tion automatically without any manual intervention from the 
operator. 

Map Loader APIs. These APIs allow the customers topology 
to be loaded into the FMP without having to add the objects 
manually into the FMP topology. This is extremely useful 



because the number of objects being managed can range 
anywhere from 4000 to more than 40,000. Map loader appli- 
1 mi ions can be written to access the topology database of 
rlu j customer and then populate the FMP topology using the 
map loader APIs. 

Conclusion 

The FMP APIs have led to the expansion of the number of 
products integral ed under the OEMF umbrella. The FMP 
integrated with other best-in-class applications provides an 
enhanced telecom network management solution lor effi- 
cient management of the mult i vend or, multi-equipment tele- 
communications net works of today. 
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HP OpenView Event Correlation 
Services 



When a fault occurs in a telecommunications system, it can cause an 
event storm of several hundred events per second for tens of seconds. HP 
OpenView Event Correlation Services (ECS) helps operators interpret such 
storms. It consists of an ECS Designer for the interactive development of 
correlation rules and an ECS engine for execution of these rules 

by Kenneth R. Sheers 



Mi Klein telecommunication technologies such as SDH/S" I 
NET (Synchronous Digital Hierarchy/Synchronous Optical 
Network) and ATM (Asynchronous Transfer Mode) ran gen- 
erate large numbers of events when a fault occurs. Every 
logical and physical element involved in delivering a service 
that uses The failed or faulty element can generate multiple 
events. This can result in an event storm of several hundred 
events pel second for tens of seconds. The task of telecom- 
munications operations staff is to determine the underlying 
cause from the thousands of events presented to them. 

1 IP OpenView Event Correlation Services f E< "Sj is designed 
to deal with the problems associated with event storms in 
l he lelecoiraminications environment Hie theory from which 
HP OpenView FJ S fceGnnology has evolved was developed 
by HP Laboratories in Bristol, England. 1 K< 
two distinct components; the B< S engine and the ECS De- 
signer. 

The FJ S engine is a run-lime correlation engine. It executes 
a set of downloaded Correlation rules that control the pro- 
< -essing of event streams. At first release, the BCS correla- 
tion engine is integrated into the HP OpenView Distributed 
Management t DM) postmaster. 

The ECS Designer is a graphical user Interface (Gf I) devel- 
opment environment that allows the correlation Riles to be 
developed interactively by selecting, connecting, and config- 
uring logical processing blocks. Once the rules have been 
created, their operation can be* simulated and visualized using 
a log of events inpu r n .• r ion engine attached to the 

ECS Designer, with the engines concept of time controDed 
by I lie ECS Designer 

The correlation rules are created using a visual paradigm of 
nodes i-oiioer-ted together to form a correlation circuit. 
Events logiealk enter nodes via input ports and leave via 
output ports. An output port of one node is connected to an 
input pott of another node in the circuit, so that events flow 
through the circuit from one node to the next. The functional 
node types provided with E< S are a superset of the basic 
types considered necessary 7 and sufficient to perform real- 
time event correlation. 

An event correlation circuit, Fig. 1, constitutes a set of cor- 
relation rules that can be compiled and downloaded to an 
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Fig, 1, Generic cortidailon ctoeuiJ i '> rn Nation rules are specified 
i ■, n i [f&tiits 

event correlation engine. Il consists of a series of intercon- 
nected and appropriately configured nodes, together with 
any associated data and relationship information Pig, 2 
shows the ECS architecture and the relationship of the cor- 
relation circuit to the ECS Designer and the Kt S engine. 

Real-Time Engine 

A key differentiator of ECS compared with other correlation 
systems is rluii it operates in real lime while taking into 
account the real-world problem dial events will often be 
tyed in the management network and delivered to the 
correlation system out of order. 

If events always arrived in bursts, it would be possible to 
buffer them on receipt and perform the correlation bet* 
hursts. However, event storms may be continuous, and the 
correlation engine should be capable of receiving the events, 
decoding them, and correlating them at the speed at which 
they arrive, continuously, without needing a mainframe to 
do the work. In ECS, any buffering required for correlation 
of time-separated events is dynamic and completely inir- 
grated into the normal engine operatioi i 

In an ideal environment, a correlation engine is embedded 
into each piece of equipment that generates events. Corre- 
lated events fro in each piece of equipment are forwarded to 
another correlation engine where correlation across multiple 
systems is performed. This strategy reduces event m ilumes 
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Correlation Node lypes 

Fifteen prim Hive node types are supplied with HP QpenView Event Cor- 
relation Services (ECS). Every correlation circuit must have one or more 
source nodes and one or more sink nodes. 

Source Nodes. This is where events enter a correlation circuit. There 
can be more than one source node in a circuit For a top-level circuit, 
source nodes are connected to the engine's input pons, where events 
are delivered by the HP OpenView DM postmaster 

Sink Nodes. This is where events leave a correlation circuit. For a top- 
Sevel circuit, the events are returned to the HP Open View DM postmaster 
for delivery to management entities that have registered to receive them. 

I; ls necessary to he able to suppress unwanted events. In the circuit 
paradigm, events are filtered by preventing them from flowing through 
different paths in the circuit. This is done by filter nodes and unless 
nodes. 

Filter Nodes. These suppress events based upon a configured expres- 
sion which typically uses the incoming event as an argument. 

Unless Nodes. These forward an event unless another event was 
created within a configured (positive or negative) time period relative to 
the creation time of the first event, and the configured (filtering) expres- 
sion evaluates false. 

Events can be delayed in the management network, especially when the 
network is stressed. This may result in delayed events and events arriv- 
ing in a different order than the order in which they were created Delay 
nodes can be used when correlation decisions depend upon events being 
processed in the strict event creation time order. 

Delay Nodes. These hold an event until me creation time is a config- 
ured number of seconds before the current time. This has the effect of 

guaranteeing that the events are output from this node in creation time 
order. 

Events may need to be stored for extended periods so that future correla- 
tion decisions can be made using the event history. Subsequently, it may 
be necessary to extract complete copies of events from the storage. 

Table Nodes. These hold a logical copy of all events sent to the table, 
subject to configured retention parameters and conditions. Other nodes 
can examine the event list stored in creation lime order, and make pro- 
cessing decisions based upon the contents, 

Extract Nodes, These search a table node and extract a copy of one or 
more events from the stored list, subject to a configured condition. The 
search is triggered by an event arriving at the input port of the extract 



node, and the extracted events are output as a composite event jsee 
"Event lypes" on page 36). 

While most of the useful information will come from the event stream, 
data may need to be obtained from outside the correlation engine. 

Annotate Nodes, These obtain data external to the engine and add it 
to an output composite event The external data is now available in the 
event for subsequent use in the downstream circuit. The annotate re- 
quest provides time for the request to be serviced, after which it will 
time out. Other events continue to be processed during this pi sri 

One of the fundamental features of ECS is the ability to collect and con- 
solidate discrete pieces of data from the event stream and from outside 
the engine to produce value-added information. Events need to be ma- 
nipulated, including combining events into a single data unit, changing 
the structure of this unit, changing event data values, and creating new 
events. 

Combine Nodes. At these nodes, two or more input event streams are 
combined into a single output stream, with each output event being a 
composite event containing an event from each input stream. Events on 
one stream can be held until events on other streams arrive. 

Rearrange Nodes. These change the structure of a composite event, 
including pulling a single normal event out of a composite 

Modify Nodes. These change attribute values of incoming events to any 
values required The values can be copied or calculated from any publicly 
available data. A copy of the original event is made, and the event copy 
is modified and output. The original event is not modified. 

Create Nodes. These create a new event with a format controlled by a 
configured specification and attribute values set according to a config- 
ured specification Event creation is triggered by an event arriving at the 
input part The events attribute values can be set from any publicly avail- 
able data throughout the engine, including from the incoming event 

Some basic utility functions are provided by the following nodes. 

Count Nodes. These count the events passing through the node. 

Clock Nodes. These generate an empty event every configured time 
interval This allows circuit logic to be triggered in the absence of any 
incoming events, enabling the absence of required events to be detected 

Rate Nodes. These calculate the rate at which events are passing 

through the node. 



All parameter values are actually expressions that can use 
references Id values stored in the data store ami lo relal u m 
ships stored in the fad sfiffllefgm "Fact Store and Data 
Store" on page 39), For example, where a value should be 
supplied for a parameter, the name of H variable defined in 
the data store can be used. The data store entries can be 
changed without changing the configuration of the node. 
Dynamic node parameters are evaluated whenever a new 
event arrives at the inpul port of the node. If these parameter 
expressions reference data store or fact store entiles, updates 
to these stores will affect subsequent parameter evaluations, 
Tins allows the behavior of a correlation circuit to be modi- 
fied dynamically. 



Like any primitive node, a compound node can have param- 
eters that must be set or configured when the node is instan- 
tiated The parameters axe defined and documented by the 
designer of $te compound node. 

Ports 

All nodes have one or more ports, which are visible in the 
ECS Designer Nodes are interconnected via potts appropri- 
ate to the required functionality; Depending upon lype, nodes 
can have input ports, output ports, error potts, reset ports, 
and other types of ports* Normal operations occur t hrough 
die normal input and output pons. For a filter node, the con- 
figured expression should evaluate true or false, causing the 
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Incoming event to be routed to the true output or the false 
output port as appropriate. 

Where run-time errors occur in evaluating the expressions 
configured for particular node instances (not everything can 
be known before run time), an event will be oulpui ih rough 
an error output port. 

Except tor the combine and compound nodes, pnmiiive 
nodes have a fixed number of pons. The combine node can 
have up to 50 input ports (combining event streams}. The 
compound node cart have up to 50 u\\m\ and output port* to 
support the encapsulated functionality. 

Reset Ports 

Delay, unless, combine, and annotate nodes can hold events 
in memory associated with an input port, pending some con- 
dition becoming true. Table nodes can hold events in long- 
term memory. 

When the engine is to be stopped or the correlation circuit is 
to be modified, the future conditions ran now never be true, 
and the applicability of stored events is indeterminate in the 
context of the modified circuit. Even if the circuit were to 
be Slopped and restarted without ( -iiauge, the potential for 
pertinent events to have bcrti missed invalidates the state of 
i he correlation ( ntical events that should have been ouipui 
mag now be discarded. 
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Count Node 

The count node [Fig. 1 1 is an example of a simple node. It has a single 
parameter, infra! count, wlifCh sets the initial value of the count attribute. 
An event entering the increment input port increments the count attri- 
bute and is immediately output via the increment output port. An event 
entering the decrement input port decrements the count attribute and is 
immediately output via the decrement output port. An event entering the 
reset input port resets the count attribute to the initial count value and 
immediately exits via the reset output port At least an increment input 
port or a decrement input port must be configured or the compiler will 
generate an error. All output port connections are optional, and events 
routed to unconnected pons are discarded. The default value for initial 
count is zero. The count attribute is exported as a read-only attribute, 
which can be referenced in node parameters and expressions as <count- 
nodenamexcount. If both the increment input and decrement input ports 
are connected, the count attribute will indicate the difference in the 
number of events entering these ports. 

Count Node 




Environment 
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Input 
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Input 

Reset In put 
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Fig, 1. Count node. 
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It is necessary to be able to output the stored events before 
engine reset or reload so that potentially critical events are 
not lost. All nodes that store events have reset input and 
reset output ports. If an event is forwarded to a nodes reset 
input port, any stored events will be output or discarded in a 
defined manner The reset event will be output via the 
node's reset output port, possibly to a downstream node's 
reset input port, allowing a reset circuit to be added to an 
operational circuit. 

Public Data 

The nodes of a correlation eireuii typically make decisions 
and perform actions based upon the arriving events, the 
information within the events, and the current rime of the 
engine. Other data is also available to the dynamic node 
expression parameters to condol node processing, including 
node attributes, the data and fact stores, and annotation data. 

Node Attributes, A node can export one or more data values 
for use by expression and condition parameters configured 



for other nodes throughout the circuit. The count node ex- 
ports a count attribute which increments or decrements for 
each arriving event, The table node exports two attributes: a 
count attribute whose value is the number of events currently 
stored and a contents attribute whose value is a list of all 
events stored in the table. 

Compound nodes can export, the attributes of any contained 
nodes as attributes of the compound node. If they are not 
exported, the attributes of internal nodes are private to the 
compound node and will not be visible outside the compound 
node. 

Data and Fact Store. The data store contains entries of name- 
value pairs and the fact store contains entries of name- 
relation-name triples (see page 39). These stores operate as 
in-niemory databases and are accessible globally throughout 
the correlation circuit. 

The data store entries allow values to be referenced by name, 
so that particular values need not be known when the circuit 
is designed. Using indirection through the data store also 
allows correlation circuits to be reused at multiple sites, with 
specialization via appropriate data store values. 

The fact store allows the relationships between objects to 
be tested by node parameter conditions and expressions. 
Typically the entries will be used to reflect network topology 
information, and will allow event relationships to be deter- 
mined dynamically without building the network model 
information into the actual correlation circuit. 

Annotation. An annotate node (see page 40) can he used to 
obtain data from outside the correlation engine for use 
within the engine, This data will be used to make correlation 
decision, or to add to created events or modified events. 

Event Types 

Several event types can logically exist within a circuit. These 
include primitive events, composite events, and temporary 
events. 

Primitive Events. A primitive event is a single event as it 
entered the correlation engine, possibly with data values 
modified within the circuit, or an event created within die 
engine, suitable to be returned to the external environment 
ECS currently supports CM IP (Common Management Infor- 
mation Protocol ISO/IEC 9596-1) and SNMPvl (Simple Net- 
work Management Protocol version 1) event types. The 
engine isolates the external event type from the internal 
functionality using specific decode and encode modules for 
each event type, This modular design allows additional 
event types to be supported in the future. Since the internal 
processing is not dependent upon the format of primitive 
extents, it is possible to correlate events of any supported 
type with events of any other supported type. 

Composite Events. A composite event is an ECS internal 
mechanism that allows multiple events to be collected into 
a single addressable structure in which all members are ac- 
cessible (Fig. 6). The event aggregation capability is funda- 
mentally important for ECS- Collecting and processing mul- 
tiple events as a single event allows all important, information 
to he collected together Members of a composite eve! it can 
be primitive, composite, or temporary events. A composite 
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Unless Node 



The unless node (Fig 1 ) is an example of a complex node The unless 
node will transmit an event arriving at the inptit port (the exciting event) 
to the output port, provided that no event arrives at the inhibitor input 
port (the inhibiting event) which satisfies the criteria specified by the 
window pareme' - ondftion parameter These events can arrive 

at differed er order is supported The transit tfeiays of arnving 

events must be within the window parameter lirr 
the relevant port. If an accepted inhibiting event arrives and there is an 
accepted exciting event in memory, the condition parameter is evaluated 
If an accepted inhibiting event arrives and there is no exciting eve r 
memory, the inhibiting event weII be held pending the arrival 
accepted exciting event, at which time the condition parameter wifl be 
evaluated. The condition parameter is a Boolean expression that can 
take both the exciting event and the inhibiting event as arguments, 
For example, 

condition: input ^ventC'device") 

= inhibitor_e vent {'"device") 

will evaluate true if both events were generated by the same device 
(assuming this information is contained in the events). Any environment 



data (data store, fact store, and node attributes) can also be used in the 
condition e ' the condition evaluates false, the exciting event 

is output via the output port. Jf the condition evaluates true, the exciting 

s inhibited and is output via the inhibited sutput port rf one is 
connected, or discarded if not If the evaluation of the condition causes 
an error |e g , if a referenced event attribute does not exist), the exciting 
event will be combined with the mhi biting event and output via the error 
output port as a composite event if the emx output port js not connected, 
the composite event will be logged, tf the transit delay of the exc ' 
event does not satisfy the window parameter transit delay window, the 
event is output via the fail output port If the inhibiting event fails this 
test, it is silently discarded. The inhibiting event is never output except 
as a composite event as described above. 

An event arriving at the reset input port causes any events held En the 
memory of the input (exciting) port to be output immediately via the fail 
uutput port, and any events hetd in the inhibitor input port memory to be 
silently discarded. The reset event is immediately output via the reset 
output port. 
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event is only defined within a ronvlation engine, ami cannot 
he mil pui from a top-level cin nil hack to the environment. 
Composite events ean be passed into and out of compound 
nodes* 

Temporary Events. Where an event is required as an internal 
container for data, or where a nigger event is required, the 
engine will create a temporary event For example, die clock 
tic mIc will emit a temporary event at each clock period. There 
relevant data in this empty temporary event h can be 
used tii trigger correlation activity elsewhere in the circuit. 
Where results are returned in response to a request by an 



annotate node, a temporary event is created lo hold I he data 
and relumed to the circuit a.s a componenl of a composite 
event A temporary eveni can enter or leave a compound 
node, but it cannot be output from a top-level circuii back 
to the environment. 

Enhancing Event Information 

A fundamental value proposition of EC'S is that evenl infor- 
mation can be enhanced, Wtt# this means in reality is thai 
all available information— for example, all information rele- 
vant to some network Fault condition — is consolidated From 
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Table Node 



The table node (Fig. 1) is the only example of a special (and complex) 
node. The table node stores events for extended periods. The number at 
stored events is exported as the count attribute. All events stored in the 
table node are exported as a list of events in the contents attribute. The 
events in the contents attribute can be examined by expression and 
condition parameters of other nodes in the circuit, and extracted by the 
extract node. The table node stores a single list of events (the contents) 
in two logical areas. The currBntarea is controlled by the save until and 
max events parameters, and the retained area is controlled by the retain 
condition and delete condition parameters. The two areas have different 
mechanisms for storage. The current area is based on physical and event 
age limits, while the retained area is based on evaluated conditions, 
which typically test data values within the events. 

The current area stares each event until the creation time of the event is 
mnre than save until seconds before the current time of the correlation 
engine, or until the number of events in the region exceeds max events. 
Each event arriving at the input port is tested to see if the creation time 
of the event is less than save until seconds before the correlation engine's 
current time. Jf it is, the event is added to the current area (subject to 
the max events limit), and immediately output via the output port if con- 
nected, or discarded if the port is not connected. If the creation time of 
the event is more than save until seconds before the correlation engine's 
current time, the event is not added to the table, and is either output via 
the error output port if connected, or Jogged if the port Is not connected. 

When an event is to be retired from the current area (based on age or 
volume), the condition specified in the retain condition parameter is eval- 
uated. This is a Boolean expression that can take the retiring event as an 
argument and can access any environment data from throughout the 
circuit If the expression evaluates true, the retiring event is logically 
moved to the retained area, If the condition evaluates false, the event is 
discarded. Events are retained in the retained area until they meet the 
condition specified in the delete condition parameter The condition is 
tested for all events in the retasned area whenever an event 
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arrives, or at each correlation engine clock cycle. Any event for which the 
condition evaluates true is silently discarded. 

An event entering the reset input port causes all stored events to be 
silently discarded and the count attribute to be set to zero. The reset 
event is immediately output via the reset output port. 




Composite Header 
I Primitive or Temporary Event 
221 Address of Element 
Fig. ti. Structure of a composite event. 



multiple time-separated events, the data store and fact store, 
and data external to the engine via annotation. 

When all pertinent information lias been assembled (j&& 
all superfluous data discarded), it must be forwarded to 
interested operations systems. This can be done by: 
Creating a new primitive event containing the eonso Li dated 
information, using the create node to create the event and 
copy the data into the event. 

Modifying U»^ data values in an existing primitive event, 
using the modify node lo change the values of the event's 
attributes before the event is output. 

The input primitive events, which each contain only a frae- 
limi of the total relevant information, ran be suppressed, 
Only the new or modified events are forwarded to interested 
management entities. The result is that the events actually 
delivered lo management systems contain enhanced infor- 
mation content. 

To aggregate all pertinent data into the delivered events, it is 
necessary to be able to collect the information together and 
process it through the engine as a single data unit. This 
allows correlation decisions to be applied to the logical block 
as a single unit, providing major efficiencies in circuit design 
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Fact Store and Data Store 

The data store and fact store permit business, topology, ar*d operating 
factors specific to a device or a set of circumstances in a maftsgec 
work to be separated from the general correlation rules defir- 
corre : * The behavior of the correlation circuit jnged 

by updating the data and fact stores as local conditions change without 
after jf the correlation circuit This ma- le to 

p correlation circuits that are data-driven, promoting circuit reus- 
ability and reliability ami design gene* s 

The data store conta i ns a set of n ame- va I u e pa i rs - if ned 

names can be used to identify the assigned values. In a circuit, ihe value 
can be referenced using the configured name. If the reference is by a 
static node parameter, the reference will be resolved at circuit load trme 
For dynamic parameters, references are resolved every time an event 
triggers activity at the node. 

The fact store contains triples: thing! -reJation-thing2. A relationship can 
be any user-defined concept, such as is_contained_in, is_the_parBnt_of, 
is_equal_to, is_gzumped_by, and so on The related things can also be 

anything the user requires in the circuit, such as switch!, rack! 7 cafai- 
neilO, circuitABC, and so on. This means that a fact such as equipmentlO 
is^containedjn rack27 can be defined. In a circuit node, a condition 
parameter can test whether this relationship is true and take appropriate 
action if it is. 

The fact and data stores are loaded from files into memory. This model 
conforms with the notion that the run-time engine is designed for very 
high speed— faster than normal file I/O speeds The stores can be 
updated while the correlation engine is running, resulting in dynamic 
changes to the corral ait on rules, 



and processing toads, Composite events are user! to aggre- 
euts into a single unit 

Event Processing 

When an event is received by tin- correlation engine it rnusl 
I 'i decoded from the specific format (BER encoded*) suffi- 
ciently to determine the event creation time and the event 
identification. These values are fundamental ro tin -operation 

of ECS. The creation tame must be known toalkro the time 
relationships between events to lie known. The event identi- 
ficatiou can he used explicilh in ronlrol which branch of 
the circuit ihe event will logically enter 

HP opei i View ECS has been ele>ianed for high performance. 
Event encoding and decocting, and event copying wiihin di> 
engine, are implemented using ajust-in-time encode and 
di eode iue< hanism and sophisticated systems of header 
structure lists, eveni lists, pointers, and reference counts 
An event is not fully decoded if not required by the correla- 
tion rule parameter expressions. References to events pass 
from node to node, rather than active events or copies of 

':fS. 

W I nil 831 event is forwarded dowil multiple paths in a circuit. 
reference counts are incremented. Only when one of these 

logical copies is modified (say with ih<- modifj node), is the 

h BEfi ^nds for Basic Encoding fluJes|iSO/iEC BB25, ITU-T X 2091. 0»Kfi define how ASN.1 
IP Syntax Notation 1. ITU-T X.20BI tfata types are encoded to be transported on the 
Both of the primitive event types supported by HP OperMew ECS. that is r SNMP 
1 tip notifiqationi IngBEfl 



at duplicated before modification. When the reference 
count is decremented to zero, possibly when the event is 
output from the circuit, the event is removed from the event 
list 

Retained Events 

The transit delay of an event is defined as the number of 
seconds between the creation time of an event am : 
that the correlation engine i assuming that 

both clocks are synchronized 

The example previously used considered the case in which 
an event A has arrived and a consequential event B is sup- 
pressed when it subsequently arrives. The correlation Hit 
consider the permissible transit delay range for event A to 
cover the situation in which event A arrives after event B. 
This requires that either event A or event B be retained in 
the circuit at the point where the condition is being tested. 
In a real-time engine, in which memory resources must be 
D 'iiserved, the event should be retained only while there is a 
possibility that it may be required in an active correlation, 
and automatically destroyed when no longer required. 

A circuit nutst be configured with a transit delay window, 
which acts as an initial filter to eliminate any events with 
creation rimes outside this window relative to the correla- 
tion engine time. The circuit transit delay window is propa- 
gated into the circuit to calculate the i ransil delay limits on 
all nodes whose operation depends on event time differ- 
ences. U a node imposes an additional time window for 
event comparisons (e.g., an unless nodi? allows an inhibiting 
eveni to occur at some time offset from the exciting event (, 
the allowable transit delays for the subsequent circuit are 
automatically adjusted lo inelude (lie additional possible 
transit delay. 

Events < an be retained in port or node memory pending s< uue 
condition b&GOmlhg true. Each such event will be examined 
.ii each engine clock cycle to ensure that the creation time 
relative to the engine time is within the computed transit 
delay window at that point Events failing lo meel this re- 
quirement are released from memory automatically. 

Data Access and GDMO MtBs 

The tests mid comparisons performed by the nodes must 
allow events to be tested for contem FA S pan « ii tes high-level 
access to any element of an event, and has language data 
types that map onto the ASNU data types in an event, hi ECS, 
each addressable component of an event is referenced as a 
named attribute For example, an event may be significant if 
its severity attribute has a value of critical. ECS provii 
sophisticated mechanism that allows the designer to specify 
this rest Hor a lilt ei node i as: 

input^e vent ("severity") = "critical" 

This Boolean expression extracts the severity attribute of the 
input event, tests the value of the attribute, and evaluates as 
either true or false. 

The eoncept that an event has a series of attributes that have 
values ihal can he examined Or modified is fundamental to 
\a s The attributes of an event arc all the components or 
elements of an event that arc specified by rbe \tiii i Manage- 
ment Information Base) that defines the event. The MIB is 
added to Ihe underlying IIP < )pen\iew DM platform so that 
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Annotation 



The annotate node (Fig. 1)is special because it is the only node other 
than the source and sink nodes that interacts with the external environ- 
ment. It is necessary to create an external annotate server to service the 
annotation requests When an event arrives at an annotate nade r it 
causes the engine to generate a CM IP event Ian EcsAnnotate Request 
notification! which is transmitted to the annotate server via the HP Open- 
View DM postmaster (pmd! and the XMP iX/Open'^' Management Proto- 
col) application programming interface. The server must have registered 
with HP OpenView DM to receive the annotate request event, Any data 
from the incoming event, or from elsewhere in the circuit, can be output 
with the request. This data is used to parameterize the request. The 
annotate server must perform some user-implemented action or inquiry 
to obtain the information required by the request. The server will return 
the obtained data to the requesting annotate node with another CMIP 
event (an EcsAnnotateRssponse notification) issued by the server (acting 



as an agent entity). The response must be returned within a configured 
time limit or the request will time out. Any required data can be returned 
(subject to the limits of the protocol). All ECS data types are supported 
[string, integer, real, time, duration, Boolean, list tuple, etc.), including 
any combination of these types. The data in both the request and the 
response is specified as a list. Since all requests use the same CMIP 
event, it is necessary for the designer of the annotate server to specify 
some mechanism to differentiate between requests. The response event 
will include the requesting node name and request ID provided in the 
request event. These are used to route the response to the requesting 
annotate node. 

The end user must create the annotate server. Examples of the server's 
agent and manager functions are provided as source code along with 
guidelines. 
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it can be accessed by the correlation engine. MIBs must con- 
form to the GDMO model (Guidelines for the Definition of 
Managed Objects. ISO/IEC 10165^, ITU-T X.722) or the HP 
OpenView DM platform will not accept them. Once part of 
the platform, ECS accesses the components of the events 
using the textual names from the MIB registration tree. The 
MIB is described in the article on page 52, 

Language 

Underlying the ECS Designer GUI is a complex and sophisti- 
cated language called ECDL (Even! Correlation Description 
Language), which supports the complete specification of the 
correlation circuit including all the dynamic node expressions 
and conditions. ECDL includes data types, operations, and 
functions that allow T read access to all component data in 
the events as they traverse the circuit, and to all public data 
within the circuit, (Event attributes can be altered with the 
modify node.) The ECS Designer ensures that the circuit 



designer does not need to understand this language in great 
detail The circuit is specified by the visual interconnection 
of selected nodes. Node parameters are specified wherever 
possible using simple ECDL constructs and supplied library 
functions written using ECDL or actually built into ECDL. 
Advanced users are able to create specialized reusable func- 
tions. The ECDL code produced by the ECS Designer is en- 
crypted in source form and compiled for downloading to the 
correlation engine. Direct coding using ECDL is not sup- 
ported and cannot be compiled. 

Building and Testing Correlation Circuits 

The ECS Designer (which includes circuit design and simu- 
late modes) is a GUI that allows the circuit designer to use 
a highly productive intuitive paradigm to build a correlation 
circuit by inter connecting primitive and compound nodes 
(see Fig. 7). 
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Fig* 7. Constructing a correlation 
using i he ECS Designer 

GUI. 



In ECS Designer build mode, nodes are selected from (lie tool 
I i*i kik'. placed on flu i-anvas, and interconnected to Conn 
the correlation circuit Subsets of the ( hcuii can he encap- 
sulated ;»s compound nodes in improve readability, Impte- 
r i ii 1 1 r top down design rules, pi promote reuse. Each node 
must be configured with appropriate values or expressions 
for its parameters. The general flow of events is determined 
by the circuit layout, subject To the conditions imposed by 
individual node parameters. 

When the circuit is complete, the ECS Designer can be 

switched to simulate mode. In I his mode, events can be 
input to the circuit to allow visualization of the Mow of 
events through the circuit. 

Various visual techniques are used to provide circuil opera 
immi feedback to ftiedrcuU designer, Events can be input in 
\ ai ions modes: stepped by even! or by time, free-run at 
selectable speed until a breakpoint, and others. The status 
of each node can be examined at am time, Pm instance, the 
contents Of table nodes can fee examined, die number of 
events through various ports can be checked, and so on. 

In the simulate mode, events are input to the circuit from ;m 
input event log, the circuit designer can view boih the input 
events and the correlated output events by means ot associ- 
ated eveni browsers, 

The simulation is performed using a fully functional correla- 
tion engine, except that the engine dors not free-run. The 
,..■>> notion oft&ne is under the control of the simulator. 



When a circuit has been developed and tested, the ECS 
Designer is used to compile the circuit so that it can be 
down-loaded into correlation engines, possible in remote 

local ions, 

'J lie • vent log that is input to the B< s simulator is in a stmc- 

lured AS( II format, allowing the events 10 be manually 
i nihil - <r ediied. h is desirable tp use a log of real evenis. 
and to coiled them automatically, SuppOll Ls provider I in 

Dolled real events in the required format It may beneces 
^iiy to make some simple edits to iliis event log to simulate 

the possible worsH-nse transii delays, 

HP GpenVIew DM Interfacing 

The correlation engine is integrated with (he UP* tpenView 
Distributed Management (DM) postmaster, ensuring that 
correlation is applied at a common point so that all events 
can be subjected to correlation {see Figs. 2 atvd 8), 
relation engine can be installed wherever an HP Open View 
DM platform is installed. The distributed nature of HP i >pen- 
\ "iew I W event management services allows a dish ibuted 
hierarchy of correlation engines to he readily implemented. 

Adding correlation engines to the HPt ^penView MM post- 
masters is transparent to existing agent and manager enti- 
ties communicating via the postmasters, except dun events 
can now be correlated If the Loaded correlation circuit were 

to pass all events, there would he no observable difference 
ill the operation of these entities, or in the events being 
generated and received 
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Network Managcmem Applications 




SMF = System Management 
tvems Functions 

XMP = X/Open Management 
Pro toe d 1 1 Application 
Programming Interface) 

DPI = HP OpenView DM Open 
Protocol Interface 

(AJ Unconfirmed CM IP events are routed to ECS. 

8 All SNMP traps are routed to ECS. 

( C) Correlated even is ^CMIPanclSNMP) routed to logs hy pmd. 

Correlated events (CMIP and SNMPf routed 10 XMP by pmd, 

E Logged events routed to XMP by pmd. 

F Confirmed CMIP events do not enter ECS {could be logged), 

Fig. S. Event routing &*an$ ]h>m HP Open View Event. Correlation 
Services. 

The HP Open View DM platform is described in the article on 
page 6. 

Events entering the postmaster are routed to the correlation 
engine where they may be accepted into the engine depend- 
ing upon the configuration of the circuit input ports (see 



Fig, 8). Confirmed CMIP events an n xiiafcely returned to 

the postmaster by the correlation engine, ft is normally 
expected that a management entity will receive a confirmed 
event, and that the confirmation is returned as a consequence 
of some action having been taken, frequently by an operator. 
Typically, if the confirmation is not returned, the agent entity 
that generated the even! will issue another (possibly differ- 
ent) event. The operation of the agent entity may be effected 
by the absence of the confirmation. If confirmed events 
were accepted into 1 he correlation engine where they were 
subsequently suppressed as part of the correlation, the con- 
firmation would not be returned since the normal receiving 
entities would never see the event. Conversely, if the cor- 
relation engine generates the confirmation, the agent entity 
can modify its function based upon the assumption that an 
operator has seen the event and taken appropriate action. 

The input ports of the correlation engine must be configured 
to accept all events received or they will be filtered out and 
discarded by the engine. Where significant events are ex- 
pected for which correlation has not been designed into the 
circuit , a branch of the circuit can be arranged as a pass- 
through to transmit all events not explicitly handled by the 
other circuit branches. 
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A Modeling Toolset for the Analysis 
and Design of OSI Network 
Management Objects 

To deal with the complexity of network management standards and the 
increasing demand to deploy network management applications quickly, 
analysts and designers need a set of tools to help them quickly and easily 
model define, and develop new network management objects. 

by Jacqueline A, Bray 



The HP GDMO (Guidelines for the Definition of Managed 
Objects) Modeling Toolset (GMT) is the first tool in the IIP 
* IpenView TMN i Telecommunications Management Network) 
developer too] chain « Fig- 1 I This toolset ci msists of a set of 
integrated tools designed to aid developers in the analysis 
and design of OSI network object models. The key compo- 
nents of the toolset are a graphical modeling tool, import 
and export facilities, and a conformance report generator. 
The tools operate independently of other HP Open View prod- 
ucts so that network specifiers can work independently of 
implement ers. This article provides an overview of the net- 
work modeling process, GDMO, and the modeling tools. 

The Modeling Process 

The first step in developing a network object model is the 
analysis of the environment to be managed, The network 
and system resources to be managed are identified and then 
characteristics and the operations that can be performed 
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upon them are defined. The managed resources might be 
physical (e.g., a router or workstation) or logical (e.g.. a 
software process). A managed resource might also repre- 
sent a collection of different resources. Other elements 
might he managed that are not actually resources but are 
required to support management Functions, such as an event 
log. These requirements are translated into a GDMO object 
model, with the managed resources represented as managed 
objects. The managed objects define the interface to a man- 
aged resource 

GDMO 

The Guidelines for the Definition of Managed Objects is an 
ISO standard tISO/IKC lOlfi^-l | ]T( " \ 722)) 1 thai defines 
how network objects and their behavior are to be specified, 
including the syntax and semantics, This specification lan- 
guage allows network object designers and in igeut 

implementers to communicate designs and btdld upon exist- 
ing designs. (JDMO is an object -oriented environment, using 
the concepts of inheritance, containment, and encapsulation 
It is used to define 

• Managed object classes for managed resources 

• Attributes and behaviors of a managed object 

| derations that can be performed on an attribute or object 

• Notifications (events) an objed might issue 

• Relationships with other managed objects 

■ The names of object instances. 

GI>MO is organized into templates, which an- standard for- 
mats used in the definition of" a particular aspect of the <ih- 

i ert, v\ itii rules tor how these templates refer to each other, 
A complete object definition is a combination of interrelated 
templates. There are nine of these templates. 

• Managed object doss ternpkltes define a model for managed 
object insiances that share the same charac ten sties. The 
inheritance relaiionships with other managed object classes 
are specified, along with the packages that define the class 
characteristics, 

• Parkatff trtujifntfs are groups of logically related sets of 
behaviors, attributes, attribute uroups, actions, notifications, 

and parameters. With each attribute is a property Jistof 

valid operations (Get, Replace. Add. and Remove), initial values, 
and other value characterise lea 
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• Behavior templates describe, in textual form, the behavior 
of a component 

• Attribute templates define an actual data element of an 
object, including its syntax and behavior. 

• Attribute group templates define a set of attributes to allow 
operations to be performed on the group as a whole. 

■ Action templates define additional operations for a managed 
objecr that cannot he modeled using the standard operations 
defined in the package template, 

• Notification templates define unsolicited events that may 
be sent by the agent. 

• Parameter templates define error conditions specific to the 
object and extend the definition of informal ion used by 
actions and notifications. The context within which this 
parameter can be used is specified. 

• Name binding templates define where an object may be lo- 
cated in the global containment tree, along with the attribute 
used to distinguish object instances, These templates also 
specify rules for the creation and deletion of the object 
instances. 

An example of each of these templates can be found in 
Appendix A, which shows a portion of a GDMO definition 
for a UNIX® password Hie ( i t\, /etc/passwd). The details of 
the information to be exchanged between the manager and 
agent are defined using ASN, I (Abstract Syntax Notation 
One). 2 ASN.I Ls a formal description language used to define 
data types to be exchanged between systems. It includes 
primitive datatypes, such as integer and Boolean, and allows 
new data types to be constructed from these types. The dara 
types are grouped into one or more ASN.I modules within a 
GDMO definition. In the example in Appendix A h there is one 
ASN.I module named PasswordFilelnfo. The GDMO templates 
reference ASN.I data types by prefixing the data type with 
lite ASN,1 module name (e.g., Password File Info, Login N a meSyntax 
in tlie login Name attribute template). 

Other ISO standards also relate to the definition of manage- 
rial ii object models. For example, The Management Informa- 
tion Model 3 is a companion document that defines modeling 
concepts, principles of naming and relationships, and scoping 
and filtering. Another example is ihe standard for the Defini- 
tion of Management Information. 4 This standard defines, in 
GDMO and ASN.I. a set of managed object classes to be used 
as superclasses. It Includes an object class named tap, from 
which every other managed object class ultimately derives. 
The other classes form an inheritance hierarchy, vvilh top as 
the root. The object class top includes attributes for object 
instance naming, which the other classes inherit. The set i tf 
rules Tor defining managed objects is referred to as the 
Structure of Miutaycment Infonufit/ou. 

The Toolset 

The GDMO modeling toolset stores the GDMO and ASN. 1 
definitions in an object dictionary; which acts as a central 
repository for all the tools (see Fig, 2 1 The toolset allows 
concurrent access to the tools and object dictionary and can 
he configured as a client/server architecture. GDMO and 
ASN. t definitions are organized within documents. An im- 
port facility allows external standard and user-defined GDMO 
document Hies, sueh as ITU-T X.72L to be loaded into the 
object dictionary, ( X721 and other GDMO standards are 
included with the toolset.) New object classes can inherit 
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Fig. 2. The GDMO modeling tm I set 

from any object class in the object dictionary and reference 
other templates and data types for consistency and reuse of 
specifications. Within the toolset, each document has a short 
alias name to simplify references to documents. Object defi- 
nitions can be added to new or existing documents. 

The graphical modeling tool can be used to learn the syntax 
of ihe GDMO language, to explore existing GDMO docu- 
ments, and to create new ones. A template window exists 
for each of the nine GDMO template types. These windows 
show the de tails of an existing template or guide users in 
creating new templates. For example. Fig + 3 shows the tem- 
plate for a managed object class, with the GDMO keywords 
along the left (requiring no entry) and the specific entries 
for i Ins managed object class entered in the table. Clicking 
the name of one of the referenced templates, such as the 
Characterized By Package template, and clicking on the Details 
burton, displays the window for that particular template. 
The Package template window displays entries for several 
h-inplate types, including Attributes. Clicking on Details for an 
attribute in that window would display its Attribute template. 
In tills way, successively more detailed information can be 
viewed until the lowest level, the ASN.I definition is reached. 

Browsers for each of the template types can be invoked to 
display a list of all available entries of that type. A filter 
function Ls available in the browsers to display subsets of 
the complete list. Template entry names can be copied into 
another template window without retyping the name hy 
selecting an entry with ihe mouse and then clicking the 
Insert bill ton in the appropriate template. The Details button 
described above also functions in the same way w r hile in ihe 
browser windows. This detailed drilbdown capability is 
available throughout the tool. 

Two useful features for cross-reference checking the object 
model are the Viewpoint and Inherited Characteristics options. 
Clicking (lie Viewpoint button, available on all template and 
Viewpoint windows, displays the viewpoint for a selected 
item, hi the Viewpoint of Managed Object Class window in Fig. 4 } 
the selected object is represented by the vertical bar, the 
templates on the left reference the selected object, and the 
templates on the right are referenced by the selected object. 
The boxes on either side of the vertical bar contain the 
appropriate GDMO keywords. Above each template name is 
the template type (e.g., MOC (managed object class), PKG 
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(package), etc.). The Viewpoint window is helpful when mak- 
ing changes to an object to verify Ghat i hose changes will not 
adversely affect other objects that are dependent upon it. 

Clicking Views and then the Inherited Characteristics button, 
available only on managed object class template windows, 
displays the window shown in Fig. 5, The characteristics 
available to a managed object class, whether specialized in 
that object class definition or inherited from an ancestor, 
can be displayed by selecting the characteristics of interest 
(Attributes, Notifications, etc. j from the row of buttons under 
Characteristics to Display and then clicking Compute. The scrolled 
window lists all of the inherited characteristics available and 
where they were referenced. Clicking on a characteristic 
and then the Details button displays its template. 

The graphs available in the GDMO toolset represent three 
distinct and independent tree structures used in OSI system 
management. These graphs are the inheritance graph, the 
registration graph, and the name binding graph. The inheri- 
tance graph (Fig. 6) shows the inheritance hierarchy of all 
the managed object classes in a selected GDMO document, 
along with any superclasses derived from other documents. 
(Ail of the tool windows handle referencing across docu- 
ments. When a template is referenced from another docu- 
ment, the template is prefaced with the document alias J 
Object class nodes can also be added or deleted on this 
graph. GDMO and the GDMO toolset both support multiple 
inheritance, which allows classes to inherit properties from 
more than one superclass. 

The registration graph (Fig. 7) shows part of I lie registration 
tree of object identifiers defined in ITU-T Recommendation 
X J2L 4 An object identifier is a unique ASN. 1 data type that is 
a sequence of nonnegative integers representing a particular 
object GDMO describes the registration tree structure 



adopted in the OSI system management standards for allo- 
cating globally unique identifiers to components of managed 
object definitions. Objects can be registered via the registra- 
tion browser or the registration tree. Registration is typically 
done in the last phase of GDMO modeling, w r hen document 
definitions are stable, 

The name binding graph (Fig. 8 J displays the containment 
relationships defined via the name binding template. The 
name binding template specifies a subordinate (contained ) 
object and a superior (containing) object, along with an 
attribute of the subordinate object that will be used to name 
instances of that class. The name binding template also speci- 
fies whether object instances can be created and deleted via 
remote management, along with any limitations on those 
actions. For example, it may specify that an object instance 
can be deleted via remote management, but only if that ob- 
ject instance does not contain other objects. This contain- 
ment hierarchy represents the structure of the Management 
Information Base (MIR). It show T s the objects an agent con- 
tains and the hierarchy and containment of those objects, 
which are used not only to define the MIR structure but also 
as a means of unambiguously referencing object instances.* 1 

Once the GDMO document is complete, the semantic checker 
verifies that the specifications are complete and correct li 
checks references throughout the object dictionary; including 
the detection of templates that are defined but unreferenced. 
The document can then be exported to an ASCII file for sub- 
sequent use by code gene rat ore, such as the IIP Op en View 
Managed Object Toolkit and other tools. The ASCII file con- 
tains both the GDMO definitions and ASN.l modules. The 
Managed Object Toolkit is described in the article on page 52, 

The remaining tool, the conformance report generator, gen- 
erates printed reports that conform to the ISO standard: 
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Requ i tvf i I G * i fcdef i « es Jfo r Implenjeii ta i ton Co i 

we State* -tociated uri tk \hi nagi -mm t 

Information { ISO/1 L « IT. -T "_ I ig. 9 is an 

example of a proforma. The designer annotates the compo- 
nent* in the report with any additional information that will 
be needed by the agent developer implementing die compo- 
nents. The agent writer will indicate m die profornia report 
. el of conformance to the definitions. 

Conclusion 

Developing a network object model and the associated 
GDMO specifications is a compli - The GDI 

Modeling X< ioJse?l dtim to i reduce the complexity and time 
involved in this delum \< m hy providing intuitive graphical 
s ano 1 object model verificatio n . 
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Appendix A: A Portion of a GDMO Definition for a UNIX Password File 

pas swordEntryManagedObjectC lass MANAGED OBJECT CLASS 
DERIVED FROM 

"Rec. X.7 21 | ISO/IEC 10165-2 : 1992 ": top; 
CHARACTERIZED BY 

passwor&EntryPackage ; 
REGISTERED AS { passwordMOCObjID 1 } ? 

pasawordEntryPackage PACKAGE 

BEHAVIOUR pas swordEntryPackageBehav ; 

ATTRIBUTES 

loginName 

GET, 
password 

INITIAL VALUE PasswordFilelnf o.paaawordlnitVal 

GET-REPLACE, 

ATTRIBUTE GROUPS 

p a a BWordEn t r y ,- 
NOTIFICATIONS 

pa a a wordEn t r y W a s C r e a t ed , 
pas swordEnt ryWasDe 1 e t ed ; 
REGISTERED AS ( paaEWordPkgQb jID 1 } ; 

passwordEntryFackageBehav BEHAVIOUR 

DEFINED AS "This is a eimple agent /manager designed to 
manipulate entries in a UNIX password file, /etc/passwd. ..-"; 

loginName ATTRIBUTE 

WITH ATTRIBUTE SYNTAX PasswordFilelnf o . LoginNameSyntax,- 

MATCHES FOR EQUALITY; 

BEHAVIOUR loginNameBehav; 

PARAMETERS loginNameErrorParam; 

REGISTERED AS { passwordAttrObjID 1 J j 

pa a a wordEn try ATTRIBUTE GROUP 
GROUP ELEMENTS 
loginName t 
password, 

DESCRIPTION "This is the mechanism whereby an entire pasaword 
entry will be referenced in a single call."; 
REGISTERED AS { paaswordAttrGroupObjID 1 } ; 

readObjectsFromDiak ACTION 

BEHAVIOUR readObjectsBehav; 

P ARAME Tl RS re adOb j e c t a E r r or P ar am ; 

WITH INFORMATION SYNTAX PasswordFilelnf o . FileNameSyntax; 

WITH reply syntax PasswordFilelnf o . Success Syntax? | 

REGISTERED AS { pasawordAct ionObj ID 1 } ; 

pas swordEnt ryWaaCrea ted NOTIFICATION 

BEHAVIOUR pasawordWasCreatedBehav,- 

WITH INFORMATION SYNTAX PaaawordFilelnf o* LoginName Syntax; 
REGISTERED AS { passwordNOtif yObj IB 1 } ; 

loginNameErrorParam PARAMETER 

CONTEXT SPECIFIC -ERROR; 

WITH SYNTAX PasswordFilelnf o.LoginNameError; 

BEHAVIOUR loginNameErrorBehav; 

REGISTERED AS { passwordParamObjID 1 } ; 

pasawordEntryNameBinding NAME BINDING 

SUBORDINATE OBJECT CLASS passwordEntryManagedObjectCIasa; 
NAMED BY SUPERIOR OBJECT CLASS paaswordRootManagedGbjectClass; 
WITH ATTRIBUTE loginName; 

BEHAVIOUR paaawordEntryNameBindingBehav ; 

CREATE W.ITH-REFERENCE-OBJECT; 

DELETE DELETES - CONTAINED -OBJECT S; 
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REGISTERED AS { passvordNaineBindObj ID 1 

— ASN.I Definitions 

FasswordFiielnfo { i 3 6 1 4 1 11 1001 11) 

DEFINITIONS : t e BEGIN 

[jiaxName Length INTEGER i : = 3 

LoginNameSyntax ■. : = General St ring (SIZE(maxNajaeLength) > 

passwordBaseObj ID OBJECT IIENTIFIER ::={13614111 1001 J 
passwordAttrObjID OBJECT IDENTIFIER ::= ( passwordBaeeOb j ID 2 } 

paaswordMOCObjID OBJECT IDENTIFIER tz* { passwordBaseObjID 8 J 

END 

-- The passwd example is provided with various HP OpenView TKK products. 
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A Toolkit for Developing TMN 
Manager/Agent Applications 

Developing manager and agent applications for telecommunications 
network management that conform to standards can be a time-consuming 
task because of the number of APIs and data types involved in dealing 
with network data and protocols. The HP OpenView Managed Object 
Toolkit aids and accelerates the development of these TMN applications. 

by Lisa A. Speaker 



Telecommunications Management Network (TMN) applica- 
tion developers have to implement targe, complex solutions 
to manage today's heterogeneous and distributed telecom- 
munication networks. Telecommunication sendee providers 
(earners) rely on interoperability slant lards to integrate ami 
deploy lliese solutions in a heterogeneous environment. 
Developing Ihese solutions to run form to staiu lards is a 
time-consuming l ask. 

I his ulicle will provide an overview of the challenges in- 
volved in developing OSI based TMN applications and then 
will describe the HP OpenView Managed Object Toolkit, 
which ( -an he used to accelerate the development of TMN 
appli eat ions. 

Background 

Network equipment providers and network sendee providers 
1 1 i s to rically have d e velo ped their ow n i y ira J net ary solutions 
for managing their telephone network equipment. Today, 
however, network equipment may come from different pro- 
viders, and telecommunication network operators manage 
large, heterogeneous, and distributed networks. Thus, the 
main objective tor standards being developed tor managing 
teleeommunu -a lions networks is to provide a framework for 
telecommunications management that promotes intei opera 
hilily. By introducing the concept of generic network models 
tor management, it is possible to perform general manage- 
ment of divcree equipment using generic information models 
and standard interfaces. 

In 1977, the International Organization lor Standardization 
(ISO) recognized the necessity for standards to enable the 
widespread ose of communications networks and, as a re- 
sult, established a subcommittee to initiate ihe standardiza- 
tion process, Because of the complexity of the environment, 
they concluded that no single standard wouM he sufficient 
Rather, they decided that the communication functions 
should be partitioned into more manageable components and 
organized as a communications architecture. This architec- 
ture would then form the framework for standardization. 1 

The essential elements of t lie model were developed quickly, 
but the final ISO standard (ISO 7498) was nor published until 
1984. The International Telegraph and Telephone Consultative 
< Vnumittee (CCITT) issued a technically compatible version 
as X.200. The result is a massive set of standards referred to 



as OSI (Open Systems Interconnect) systems management. 
The ISO standards and the CCTTT recommendations con- 
tinue to be developed with close collaboration. 

The term OSI systems management actually refers to a 
collection of standards lor network management that in- 
clude a management service and protocol and Ihe definition 
of a database and associated concepts^ The llrsi standard 
related to network management issued by the ISO was 
ISO 7498-4. winch specifies the management: framework for 
I lie OS! seven-layer model. Subsequently the ISO issued a 
sel of standards and draft standards for network manage- 
ment, A subsei Of these standards provides the foundation 
to] TM\ applications 

The TMN recommendations strive lo leverage the 1 OSI sys- 
leius management standards and extend them into I lie h l< 
communications network management domain As in ( >Nf 
the basic concept behind TMN is to provide an organized 
architecture and standardized interfaces, including protocols 
and messages, to achieve interconnection between various 
types of operations systems (OSs) and telecommunications 
equipment for the purpose ot exchanging management 
information. 

The OSI systems management standards fall into five 
categories: 

• An OSI management framework and overview, which 
provides a general introduction lo management concepts, 
including the OSI seven-layer model 

» The Common Management Information Service (OMIs ■ 
which provides OSI management seniles to management 
applications, and the Common Management Information 
Protocol f CMIP), which provides Ihe infonnation exchange 
capability to support CM IS 

• Systems management functions, which define the specific 

I unct inns performed by OSI systems management, including 
fault, eon figuration, accounting, performance, and security 
management 

• A management infonnation model, which defines the 
Management Information Base (MB3), a database containing 
infonnation about the resources and elements within the 

I >SJ environment that need to be managed 

• The CCITT recommendations are now called ITU-T [International Telgcommunica&njis Union 
Te lecomm un icai ion s } recorrimendati ons 
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CM IS = Common Management Information Service 
CMIP = Common Management Information Protocol 
MIB ■ Management Information Base 

> Layer management, which defines management information, 
services, and functions related to specific OSI layers. 

The fundamental function within OSI systems management 
js the exchange of management information between two 
entities: the managing system (the manager or requestor) 

and the managed system (the agent or responder) by means 
of a protocol (see Pig. 1 j (MIS pmvides thr sei\ire$, iuvok- 
ahleby die management prnress lo initiate management 

requests, and CMIP specifies the protocol data unit CFDU) 

and associated procedures for transmitting management 
requests and responses. 

i >si systems management relies heavily on the concepts of 

objeri -oriented rjesign \ mnwiged-OttfGGl Class IS a model OX 
template For managed object instances thai share similar 

■ istics. :\n osi systems management managed objed 
i lass is defined in terms of its attributes, operations that can 
he performed upon it, notifications that it may emit, and its 
relationships with other managed objects. Attributes hold 
I he data values associated with a specific managed object 
instance and may have a simple or complex structure, The 
datatype for an attribute is defined using Abstract Syntax 
Notation i tag (ASN.l). The operations affiliated with a 
managed object class are <<Iosel> associated with the (MIS 
services CREATE, DELETE, GET, SET, and ACTION. 

A managed object class can be defined fur any resource lhai 
an organization wishes to monitor or control. A single man- 
aged object class may represent a single network resont 
or a logical representation of many resources. Examples of 
hardware resources include switches, workstations. PBXs, 
LAN cards, and multiplexers. Examples of software resources 
are queuing programs, muling algorithms, and huffier manage- 
ment Examples of logical resources Include a network, a 
i, 6] a • irtuaJ prfi ate circuit 



Fig. 1. The ' KSI systems 
inert! architect no the J manager 
system and the managed system 
(ag< 

An agent application provides a view of its asso* iated 
managed objed instances, Manager applications are able to 
access the managed object instance attribute values and 
manipulate managed object instances through the manage- 
ment interfaces published by each managed object class. 

The foundation of any network management system is a 
database containing information about the resources and 
elements being managed. In OSI systems management, this 
database is railed tte Management htf&rtnation Base (Mll'i 
The MIB is a structured collection of managed object in- 
stances, together with their attributes. The MIB is typically a 
multilevel hierarchy based on the managed object class con- 
tainment relationships defined in the object model. The MIB 
hierarchy is constructed and traversed by using the ubjeei 
instances 1 distinguishing attributes. For example, in Fig. 2 ;t 
switehPort object Instance is identified by its portNum attribute! 
Its associated switchCard cardNum attribute, and its switch 
switchNum attribute (swrtchNum = 1, cardNum = 1 T portNurn =2). 

The general framework within which a MIB can be defined 
and constructed is referred to as the Structure of Manage* 
meni tTtformation t SMI 1. SMI identifies the data types that 
can be used in the MIB and how resources within the MIB 
are represented and named 

To encourage consistency between managed object defini- 
tions and to ensure (lie development of object definitions in 
a manner compatible with (he ( ISI system management stan- 
dards, the Guidelines for the Definition of Managed ( rbj< 
CGI >Mf ) | | IS( )/IEC 101654, ITl -T Recommendam m X.722 1 
has been developed. This standard provides a formal specif! - 
cation language for defining the interface for an OSI managed 
object class and the semantics for docntuenling the attributes 
and operations fbeha\ iors) associated with a managed object 

class. The specification also defines the relationships among 



October 1 1 M tfi I tewtel t • f tockan I JcrttrosI 53 



)Copr. 1949-1998 Hewlett-Packard Co. 



Mm 



switch 
swilchNunt = t jgutl 
swucfaStatug = 1 {get! 



swilchCnrd 
cardNum - 1 1 gel} 
car if Status = 1 (gel I 



swiictiCarri 
cEirriNnm = 2(geU 
cmilStaltis = 1 {yet I 



I 


| 








1 


| 


1 I 






5 witch Port 
porfNum = 1 I gel J 
[lertStaius = 1 i get/set) 
packotsln = 1D0Q (§et) 
packetsOuf * 1500 ! get 1 




swildiPun 

fiorlNum = 2 [§el) 
oorlStaUis = Qt get/set f 
packetslo = Igei) 
packetsQut = D LgeiJ 



Fig* 2. The contents of a suhsrt oTatl agent's Management 
Information Base fMIB) showing a containment tree roads 
up of nsijeii j 1 1 -. r . j 1 1 1 i ■ :-. and their attributes, 

managed object classes in the management domain. See the 
arl ielc on page 43 for more about GDMO. 

OSI Application Development 

OSI application development falls into two major categories: 
manager development and agent development. This section 
describes the development of the agent and manager applica- 
tions Without I he assistance of a toolkit. Development with a 
toolkit is discussed in the next section. 

Manager development involves the development of applica- 
tions that. Issue management requests and process agent 
responses and notifications. Notifications are messages 
transmitted by agent applications when some? trigger, such 
as a threshold or an error condition, lias been t ripper 1. 
Manager application developers must complete the tasks of: 

• Developing the user interface through whieh management 
ret 1 1 tests can be initiated and the status of managed objects 
can be viewed 

• Developing the underlying conn mi nidations for issuing 
requests and processing responses and notifications, 

Agent development involves the development of the appli- 
cation that manages the managed object instance data, 
maintains its portion of the MIB, processes inbound man- 
agement requests, and emits notifications as necessary. 
Agent application developers must complete the tasks nf: 

• Defining (usually in GDMO) the managed object classes 
associated with the resources managed by the agent 
application 

• Developing the underlying communications for processing 
management requests 

• Monitoring managed resources and emitting notifications 
as appropriate. 

X/Open°, an independent, worldwide, open systems organi- 
zation, provides application programming interfaces (APIs) 



Do facilitate the development of OSI applications. A primary 
Objective of X/Open is to promote the portability and inter- 
operability of OSI applications at the source-code level. For 
OSI systems management application developers, X/Open 
provides the X/Open OSI Abstract Data Manipulation (XOM j 
APIs and the X/Open Management Protocol (XMP) APIs. 2 >* 

XOM is a C -language interface specifically designed for use 
with application-specific APIs that provide OSI services, 
such as X.400 and CM IS. The XOM API is a set ot si rur lured 
information objects and functions for accessing objects mid 
shielding programmers from much of the complexities of 
manipulating the underlying ASN.l data types. 

XMP provides the TMN application developer with a C-lan- 
guage interface to the underlying management services con- 
sistent with l tie CMLS/CMIP and the Simple Network Man- 
agement Protocol ( S\MP). The XMP API is designed to be 
used and implemented with the XOM AIM. XOM objects 
serve as the parameters for the XMP management service 
functions (see Kig. -J). 

Manager applications initiate management requests and 
process responses returned from agent applications. XMP 
functions that support issuing management requests include: 

• mp_create_req( ): Initiates a management request to create a 
managed object instance 

• mp_get^reqf ): Initiates a management request to get data 
from a managed object instance 

• mp_set_req( J: Initiates a management request to set attributes 
in a managed object instance 

■ mp_receive{ |: Receives the agents response to support asyn- 
chronous requests or a notification emitted by an agent 

XOM objects, defined as C structures, must be created and 
passed to these functions to transfer the details of the man- 
agement request For example: 

• mp_create_req( ) requires a CMIS-Create-Argument XOM object 
and is returned a CM IS -Create -Result XOM object 

• mp_get_req( ) requires a CMIS-Get-Argument XOM object and 
is returned a CMIS-Get-Result XOM object 

• mp_set_reql ] reniures a CMIS-Set-Argument XOM object and 
is returned a CMIS-Set- Result XOM object. 



xmp_api (xom_object ) 




Or 




Fig. 3, The relate .n^rp i<Hween XOM objects and XMP manage- 
ment luuclions, XMP functions use. XOM Objects as paruui' ' 
send the details of a manager^ request via either a < Mil' or an 
SNMP protocol stack. 
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• mp_receivet I requires a CMIS-XXX-ftesiilt X< >M object, with 
type depending on the response received, and is used for 
receiving asynchronous requests. 

Fig. 4 shows the specification for the CMI5-6et*Argument X< >M 
object class, The specification shows that the BET request 
XOM ohjeet class specification also contains reference 
oiher XOM object classes. To construct a CMtS- Get- Argument 
:iil < >f its contained XOB must also be 

constructed. The complexities of developing applications 
using the XOM API can be seen. The developer is challenged 
with the tedious task of traversing several levels of nested 
XOM objects either to prepare a request or to extract data 
from a 11 

When developing agent applications using the XMP XOM 
APIs, the agent developer is responsible for creating func- 
tions to receive the request, determine The type of request 



CMIS-Get Argument XOM Object Class: 
XOM Attribute Value Syntax 



base-Managed- Object (Object-Class} 

Object class 



h a v e - M ana g ed - b j ect { b j eel -Ifista nee \ 
Object-Instance 



access-Control Object {Access-Control I 

synchronization EnumiCMIS-Syncl 

scope Object (Scope) 

litter Object ICMIS Filter) 

attribute- Id -List Object (Attribute I rl Loll 

Attribute- 1 rl- List XOM Object Class: 

XOM Ann bute Value Syntax 

attribute-Id Object (Attribute-Id] 



Class of object desig- 
nated as starting 
point of request 

Identifier of object 
designated as starting 
point of request 

Permission and secu- 
rity information 

How to synchronize 
selected object 
instances 

Subtree to tte 
searched 

Characteristics to 
test attributes 

Attribute values 10 be 
returned 



Identifier for a managed 
object attribute 



An instance of an Amibute-ld-list object will contain zero or mare attribute 
identifiers, designating whicn attribute values to retrieve in the managed 
object instance, Each attribute identifier must be constructed and has the 
following form: 

Attribuie-ID XOM Object Class: 



(CREATE. GET, SET ACTION, DELETE etc.), validate the request, 
and process the request. In validating the request, the agent 

loper must determine, for example, if the request is 
a valid object instance in the agent s management domain. 
or confirm that a SET request has been received on a modifi- 
able attribute. A significant portion of the agent development 
task is in the miplemenTai ion I Jidatioii. 

^ent developer must also manage the applicat: 
sentatioi lich is the Ln- 

process structure holding the representatiofl of the managed 
objects and their associated att s. 1 

and 2 j. As management requests are received, the agent 
application must operate on the associated managed object 
representation in the agent s containment tree to perform 
operations such as: 
» Create new entries in the containment tree as CREATE 
requests are received 

• Delete entries in the containment tree- ;ls DELETE requests 
are received 

• update entries in the containment tree as SET requests are 
received 

• Traverse the containment tree when scaped and filfpt* <t 
requests are received, 

A scoped request operates recursively on an entire branch 
of the containment tree, starting at a designated base man- 
aged object. A filtered request designates criteria that man- 
aged objects must have to have a management operation 
performed. Filters are an optional facility that the agent can 
provide. Scoping and Altering allow mid Li pie managed" ob- 
jects to be selected and operated upon in sen-icing a single 
management request. 

After processing the request, the agent developer must 
prepare the response by constructing the associated Xt >M 
objects and then use the XMP API u * issue the management 
response. 

The XMP API provides a collection of functions to support 
agent development, including: 

• mp_receive( ): Receives the indication of a management 
request 

• rnp_create_rsp{ \: Transmits a response to iltr manager's 
CREATE tvquesl 

• mp_get_rspf f: Transmits a response to the managers GET 
requesi 

• mp_set_rsp( }; Transmits a response in a managers SET request 

As in the manager scenario, fl&e data received by the agent 
will be in the form of mi XOM object, and the agent applica- 
tion developer must prepare an X< iIVl object to return to ih« i 
manager application after servicing the managers reqm 



XOM Anribure 
global Form 

lurjal Farm 



Value Syntax 

Siring (Object-Identifier! 

Integer 



A registered attribute 
type identifier 

Integer idenlifier 

defined as part of the 
application con text 



An instance of an Attribute-Id object will designate the attribute to be 
retrieved either Ihrourjh its global Form or its local -Form. 



Fig, 4, A specification for the CMIS-Get-Argunient X< >M oW» | \a 



HP OpenView Managed Object Toolkit 

As noted above. OSI systems management standards use 
object-oriented terhnii|ites to model applications in terms ol 
managed objects, which represent the resources in a nel- 
work. litis n takes object-oriented programming techniques, 
including the C++ programming language, a natural imple- 
mentation choice lo use for development, starting from 
object analysis to application ending. 
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i fisiur h ally, developers Implementing standards-based OSI 
applications have b&m required 60 implement the entire 
nianageniem application, agent, and manager from scratch, 
using the complex XOM/XMF .APIs and C bindings, as de 
scribed above, 

However, die OSI systems management standards precisely 
define a generic stun I me and behavior dial apply To all 
agent applications. The agent developers task can be greatly 
simplified hy implementing die generic pieces with reusable 
software components, which caaa be assembled to build 
agent applications. In addition. ( J I >MU is provided for for- 
mally defining die specific managed object class attributes 
and interfaces. Given a GDMO speri Ileal ion, it is possible to 
define a C++ class mapping representation of I he GDMO 
managed object classes. 

These two fundamental philosophies fomi the foundation 

for die HP OpenView Managed Object Toolkit (MOT). The 
Managed Object Tool Id I supplies; 

• An object-oriented agent application framework that pro- 
vides the general-purpose, reusable software components 
that make up the generic aspects of an OSI agent application 

i At i application framework is a generic application thai can 
be tailored lo meet specific requirements. It handles .ill 
generic operations lhai are common to all applications in 
a specific domain, The agent framework is provided as a 
library with the Managed Object Toolkit.) 

• A GDMO-t.o-C++ and an ASN J-lo-C++ code generator that 
provides the OSI application developer with a C++ interface 
for the implementation of the specific behaviors of a man- 
aged object in an agent application and C+ + classes for 
preparing management requests in a manager application 

• An agent application generation caj n 1 1 1 i I i 1 > thai m afges t he 
generic framework and the specific GDMO-based generated 
C++ classes iulo an operational agent application, 

Agenl application development, which previously had taken 
programmers weeks, or even months, to code using the XJVIP/ 
XOM APIs can now be generated in a matter til minutes or 
hours. The Managed Object Toolkit allows agent developers 
to focus on the implementation-specific details of their ap- 
plications, since they no longer need to be concerned with 
the tedious task of using I he XMP/XOM APIs to implement 
the CMIS communications model. 



The Agent Development Process 

Using the Managed Objed Toolkit agent development is 

accelerated with a simple five-step process (see Kig. 5): 

1. Define the GDMO managed object class specifications. The 
IIP OpenView GDMO Modeling Tools, i 1 GMT) can greatly 
simplify die design of managed object classes by providing a 
graphical, forms-based interface for defining and browsing 
GDMO managed object class definitions. It also provides a 
graphical representation of the object class inheritance and 
managed object naming hierarchies. The HP Open View 
GDMO Modeling Toolset is described in the article on 
page 4S, 

% Submit the GDMO object mode] lo the Managed Object 
Toolkit code generator This will generate C++ class repre- 
sentations of the GDM< ) managed object classes, an agent 
main(J function, makefiles to compile (lie agenl executable, 
rind an object registration Pile tor the HP OpenView Distrib- 
uted Management Platforms managed object din -en>r> ser- 
vice. The HP* rptmView Distributed Management Platform is 
described in I lie article on page 6\ 

■J. Run the provided makefile, which compiles an operational 
"default" agent, so-called because it implements default be- 
haviors for the managed object int ei faces. 

4. Register the agent s objects with the IIP * )penView Dis- 
tributed Management Platform's object directory service. 

5. Run the agent application. 

The executing agent is now ready to accept management 
requests, including CREATE, DELETE, GET, SET. mid ACTION- Sinn- 
the agenl application is also tightly integrated with I he HP 
Open View Distributed Management Platform, it is able to 
leverage platform services immediately, such as the object 
registraliou service for object location transparency and 
event, routing through the event management services. See 
the article on page 31 for more about event management 

Managed Object Toolkit Agent Capabilities 
The Managed Object Toolkit agent framework handles all 
aspects of the underlying management request and response 
communications between agenl ami manager, relieving die 
programmer of significant coding effort, including: 
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• Receiving t MIS requests I CREATE, DELETE, GET, SET, ACTION, 
err. >. and routing them to the appropriate CMIS service 
handier 

• Validating requests and transmitting standard CMIS terrors 
when invalid requests are received (For example, receiving 
a GET request on an attribute in a nonexistent managed 

oee will generate a standard NO-SUCH-OBJECT 
INSTANCE emir mcssaL 

sting and managing the nt inhumation 

>\ which holds the managed object instances and their 
attributes representing the resources managed b\ 

• Supporting 9 Eld filtered requests in winch a sir. 
request can he routed to several managed object instances 

• Preparing and transmitting responses, including: packaging 
multiple replies in response to a scoped request 
Emitting standard < MIS notifications w hen managed object 
instances are created, or deleted. 01 when an attribute value 
is modified 

By providing the CMIS communications handling infrast na- 
ture, the Managed < Ibjecl Toolkit frees the programmer from 
the tedious 'ask of implementing code for processing man 
ageinenl requests and responses and allows the developer to 
focus on the valm -added specific agent fund tonal it >. 

Customizing the Managed Object Toolkit Agenl 
Because specific managed ofcttect beha\ \m • be com- 

pie tely specified using c; 1 >mc », the Managed < Object Toolkit 
agent framework and the generated classes « anno! fully 
implement managed objects on their own. The framework 
provides a default object behavior, and the Managed ' Ibjecl 
Toolkit C++ rode generator provides a code skeleton tor the 
implementation The complete agenl application is built by 
generating the agenl skeleton code from the GDMO specifi- 
cation and then customizing ihe generated code stubs (C++ 
methods), 1 developers can also integral e Managed Object 
Toolkit provided classes to implernenl communications with 
external dei ices (supported through standard file dest rip 
tors) and implement a cooperative multitasking agent 

I ■'■ K example, if a managed object Class railed switchPort in- 
cludes an attribute called packetsQut which was defined iis the 
' ri i\i< I specification r be "gettable* (see Fig. 2). the Man- 
aged < Object Toolkit generates a file railed MOC_switchPort ckx 
and includes an empty method Galled get_packetsOut' 1 

MOC_switchPort*cxx (filename J 

virtual void Mot .switchFort C: rget_pack©taOut< 
OVmotMoGetHesultC & result_r) 

( 
} 

li the developer washes to override default behavior of the 

CMIS GET reqtiest for the packetsDut ath ibute to qtigtya regis- 
ter in H11 associated physical devire, the get_paekefsQut{ \ 
method is easily customized* This method includes 
response parameter, 10 which the prograrnnier assigns a 
n spouse value, and the Managed Object Tooikii agenl 
framework will appropriately package the response and 
ret run it to the rem testing manager application. 

The Managed ( object Toolkit provides significant value for 

processing requests, especially if a gat pa cketsQul request 1^ 

of a scoped request, which is a single management 
request that will operate, potentially, on several managed 
object Instances in the agenl The agent application must 



route the request to all of the relevant managed object in- 
stances, process the request, gather each of the individual 
response - them, and return them to the requestor. 

Willi the Xt KM AMP APIs, the agent developer is required to 
implement the entire process, gather all of the re*-, 
package them, and transmit the multiple responses to the 
requestor With the Managed Object Toolkit, the agent di 
implement the handlers for each 
individual request. Since the agent framework manages all 
asj 1 ) 1 lest an d response cotnmun 1 he 

framework will track the scoped request, route H to ail 
appropriate object instances in the Managed Object Toolkit- 
managed containment tree structure, colled all of die indi- 
i [dual responses appropriately, and transmit the composite 
response to the requestor. The Managed < object Toolkit- 
based agent developer is required to implement only the 
actual details of each attributes request handler. 

Implementing an ACTION operation ptoi ides another good 
Mviiarii. The CMIS ACTION service provides a general pur- 
pose object interface for implementing any operation in a 
managed object instance. For example, an action may be 
defined to reset a port on a switch \s in the GET scenario, 
the Managed ( (hirer Tooikii generates an empty C++ method 
for the programmer 1o fill in ihe specific details for servicing 
the ACTION request Bui unlike die GET scenario, the stan- 
dards rannoi specify the appropriate response to an ACTION 

ation, and GDMO does not provide syntax for the spe 
cifie implementation of an ACTION operation. Therefore, it is 
entirely the agetit developer's responsibility to provide ihe 
implementation details associated with an ACTION request. 

The following generated method provides the programmer 
with the ACTION informal ion the management application 
passed along, and as in the get scenario, an emptj result 
object ilwi the programmer nils in totransmil the agents 
response, The MOT generates a file railed MOC_switchPort .cxx. 

whirli includes the empty method rEsetPQrt_action( I 

Moc_swi tchPort . exx ( f i lename } 

virtual void Mot switcliPort„C t : reeetPort act ion £ 

const Mot resetPorc. InfoC*actinfQ.p, 

OVmot Mo ActRe suite & result_r) 

{ 

J 

Again, the Managed Object Toolkit provides significant 
value, requiring the programmer to implement only the de- 
tails of the action handler ami assign ihe art ion response, 
allowing the programmer to disregard implementing an 
Mis communications processing. 

Managed Object Toolkit Agent Framework 
In typical object-oriented design philosophy, the agent 
framework can be decomposed inio several supporting 
frameworks (see Fig. 6). Each snbframcwork. implemented 
as a class library, provides a particular categorj of Function- 
ality thai contributes to die overall agent request processing 

task. 

The agent framework is provided as a library with the Man- 
aged r )hject Toolkit and is made up of the following compo- 
nents: 

CMIS Service. This class library provider 1 -lasses that enable 

convenient access to the I MIS services, it contains base 
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Managing System 
(Manager! 



Managed System 
(Agent! 




Fig. 6. Stoaged Object Toolkit frameworks. 

Glasses l lull define 1 the CMIS services and subclasses that 
implement the CMIS services using the XMP API. 

CMIS Transactions. Tliis class library provides classes that 
implement the incoming CMIS requests. It provides an agent 
application with the functionality to process the receipt of 
CMIS CREATE, DELETE, GET, SET, and ACTION indications. 

Containment Tree Framework. This class library provides an 
infrastructure for developing a containment tree representa- 
tion. It also provides concrete classes that implement an 
in-memory representation of the containment tree. 

Management Information Syntax Framework. This class library 
provides the infrastructure for developing C++ classes that 
represent syntaxes specified in ASNM (e.g., atiribute values, 
action information, and action reply syntaxes). It provides 
base classes for representing ASN.l syntaxes. 

The Managed Object Toolkit C++ class generator generates 
C++ classes representing ASNL 1 types defined in the GDMO 
specification. These C++ classes are derived from the base 
classes provided in the management information syntax 
framework (see Pigs. 2 and 7). Pig. 7 illustrates how the 
Managed Object Toolkit generates C++ classes for GDMQ- 
defined attributes. All toolkit-generated attributes will be 



derived from the OVmatAttC C++ class provided by the 
Managed Object Toolkit. 

Managed Object Framework. This class library provides an 
infrastructure for developing managed object implementa- 
tions. It provides C++ base classes for representing man- 
aged object instances and managed object metadata. 

The Managed Object Toolkit C++ class generator will gener- 
ate C++ classes represen ling the GDMO object classes de- 
fined in the GDMO spec [Ileal ion. These C++ classes will be 
derived from the base classes provided in the managed ob- 
ject framework. The C++ inheritance hierarchy reflects the 
GDMO specified inheritance hierarchy. For example, Fig. S 



OVmotAHC 



MOT packetsDul C 



MOT- Provided Framework C++ Class for Attributes 



MDTGenerated GDMQ-Based Attribute C++ Class 



Fig, 7, The inheritance hierarchy of C++ classes 1 1 ■ i 1 1 1 l.tase 
classes provided in the management information syntax framework. 
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GDMO Inheritance Hierarchy 



switch Pon 



The communications framework classt-s aQow ihe devel- 
oper to create a pseudo multitasking, event-driven interface 
for conimtinicating with externa] devices. 

Common Application Environment This class library provides 
facilities for multilevel tracing and logging. 

Foundation Types. This class library provides classes for i 

_ i rommon data structures such as lists and strings 
and • memory management and reference counted 

objects, [I 



MOT C++ Inheritance Hierarchy 



OVmotMoC 




Mm switchPurt C 



MOT-Provirfed Framework C++ Class 



MOT- Gen crated GDMO Based Managed 
Object C++ Class 



MOT- Gene rated GDMO-Based Managed 
Object Class 



Ftg.&il* >'-- GDMl ' n heritahce fciar tri m» - 
switch Port managed ol ?■> I class- 
shows the C++ inheritance hierarchy for Hit- GDMOdefmed 
switchPort managed object i htss. En the I rDMO specification, 
the switchPon managed objeci class i.-, derived from the top 
managed class. Notice ihe similarity in the GDMO-defmed 
Inheritance hierarchy and the C++ inheritance hierarchy 
generated by die Managed i Ibjeet Toolkit. 

The managed objeci framework usesC+H dass^sfit>nn ttra 
management information syntax framework to represeni 
attribute, action, and notification syntaxes. 

CMIS ASN.1 Types. This t lass library' provides specializations 
of i he ASN.l framt -work classes for representing* MlSaigu- 
mentS fe.g.. CMIS-Create-Argumentand CMIS-Get-Argumant). 

Communications Framework. This class library provides an 
infrastructure for developing C++ classes thai ai isible 

I ur 1 1 nvii tilling con mi tinication w i M « external devices. It 
coordinates between objects responsible for different com- 
munication endpoints fffle desi Tiplorsj using an event -d riven 
environment which encapsulates the handling of the I MX 
select! \ fund ion. The library also includes concrete classes 
for handling comniuiucatlcai with the IIP open View Distrib- 
uted Management Platform process management functions. 

The cHiimiiiiiic^iinjis framework also provides ail abstract 
tasking class, based on I SI js (UNIX System Laboratories) 
task libraiy, which can be leveraged if implement a coopera- 
tive multitasking applicant hi. Kac.h task is cooperative, in 
that it owns control of a process until il exits or explicitly 
gives up control The Managed Object Toolkit ( MLS Iran s- 
n rionsarea collection of concrete task classes developed 
for processing t'M is requests. 



Using The Frameworks 
Hie class libraries are leveraged by the Manage 
Toolkit agent libraiy for processing manager requests, M 
of these classes are also externally visible, allowing applica- 
tion developers to hem for then own agent devel- 
opment needs. 

For example! when a CMIS GET request is received tin 
agent's communications framework will receive and ideiuif\ 
the get- indicate, and then construct and initiate a Managed 
Object Toolkit-defined CMIS get-transaction object instance. 
This get -transaction object will manage the overall processing 
i if the GET ret in est, Interacting with the containment tree 
framework, I be managed object framework, and the manage- 
ment information syntax franiework to complete ihe pro- 
cessing of the GET request. iThe C+4 object class representa- 
tion of the managed object instance and i he GET ham Her tot 
this request are contained in ihe managed objeci framework, 
while the syntax associated w iih the attribute value is held 
in ihe management information syntax frame work i 

An agent developer desiring in implement a multitasking 
interface to externa] entities, such as devices or databases, 
call derive a user-defined l ask class from the Managed < >b- 
ject Toolkit's absfetd tasking base class. The application 
developer then constructs and Initiates tasks in the applica 
lion code, as in 1 lie following code fragment. 

myTaek.hxx (filename) 

myTaskC; public OVmotTxnC 
{ 
public : 

myTaek [ ) ; 
execute ( J \ 

private : 

>; 

myTask.cxx (filename) 
myTaskC : : execute ( ) 
t 

// provide code for task implementation 
} 

The following code shows th<- construction and iiivi ication 
ui fcfoe above ni^k in <m«' of the I MIS sen ice handling 
routines. 

MOC_swltchFort « exx (filename) 
virtual void Mot awitchPort C: : get „packetsOut ( 
OVmotMoGet Re suite £ result_r) 



{ 



myTask ataskj // construct a task 
atask. execute £ };// run task 
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The commiinieaiions framework provides a communication 

coordinator Nun encapsulates the UNIX select! ) interface. 
Tlic communication coordinator is used by the Managed 
f fojed Toolkit agent framework to receive and process in- 
coming (MIS requests. 

The application developer can also use the communications 
coordinator to process nonCMIS-orienled conuiiunlcatious 
within the agent application. An example of this would be 
cmnnHinicating to an external device through a. serial in hi - 
face. The agent developer need only register the opened file 
descriptors with tire Managed Objeri Toolkit-provided com- 
munications coordinator and implement fhe associated com- 
mimications handler (read, write, ami exception). Then 
through ihe registration and callback mechanism, the com- 
rcmnication endpoinl processing code will be executed when 
the file descriptor triggers select! } as in the following code, 

somecc.hxx (filename) 
SomeCC : OVmotCC 
C 
public : 

SomeCC ( ) ; 
- SomeCC ( ) \ 

void doReadf int fd ); 
private : 

int fd; //File descriptor associated 
//with this communication 
//interface 

}; 

aomecccxx { filename) 
SomeCC : : SomeCC ( ) 
{ 

fd = open (...); //open a. file descriptor 
OVmotCoordC: : regis terCC (fd, 

OVmCoordC i : QVMOT_KE_READ, this ) 
// register file descriptor with MO commnica- 
// tions Coordinator 

// register for read operations, callback to 
// this->doHead ( ) when data is on fd 
} 

SomeCC : : -SomeCC { ) 

( 

OVmotCoordC: :deRegisterCC ( fd, 

OVmotCoordC: ;OVMOT KE READ r this); 
close (fd) ; 

// deregister file descriptor with MOT 
// Communications Coordinator and close file 
// descriptor 
> 

SomeCC : : doRead { int f d ) 

I 

// Receive and process the data buffered on 

// the file descriptor 

> 

When data is sensed on this open tile descriptor, the agent s 
communication coordinator will call the doReacH t method, 
processing the data on the communications interface. 

Developing Manager Applications 

Unlike the agent development process, the Managed Object 
Toolkit does not generate an executable manager applica- 
tion (see Fig. 5). For manager developers, the Managed Ob- 
ject Toolkit provides an intuitive C++ interface which encap- 
sulates the complexities of XOM object manipulations and 



assists the manager developer in the management commu 
mcations implementation aspect oi manager applications. 

Manager developers use tbe XMP API to issue requests and 
leverage the Managed Object Toolkit to build the XOM ob- 
jeri parameters required by the x MP API (see Fig. 3j + The 
manager developer has access to: 

• M an age d bj ect 1 bo 1 k i t -j ) rovi d ed C ) M IS se ni e e c 1 asses to 
build request objects and parse response objects 

» Managed Objeri Too]kil-pro\idcd convenience classes, 
which represent ttie underlying components of the (MLS 
request objects, including G++ chess representations for 

Fully distinguished names 

Attribute identifier lists 

Attribute lists 

Base managed objects for scoped requests 

Filters 

• Managed Object Toolkit-provided stream-based classes for 
transforming C-f-f request objects to XOM reiaiesl objects 
and N( KM response objects lo ( V + response objects 

• Managed Object Toolkit -generated GDMO-based C++ 
classes representing ibe managed object classes 

• Managed Object Toolkit-generated AS.V1 based C++ classes 
represent i 1 1 g I h e sy i it a xes < lss< h ial i < 1 wit h the managed ob- 
ject attributes, actions, and not locations. 

The folio whig scenario is an example of a Managed Object 
Toolkit-based manager GET request. Note that classes 11 mi 
begin with OVmotare Managed Object Toolkit-provided 
classes and classes thai begin with Mot are Managed Object 
Pool kit-generated classes originating In an the GDMO speci- 
fication, 

Scenario: Issue a scoped GET request for all of the ll tT" ports 
on a specific card in a switch and return the in and on I 
packel counts across ports thai have traffic. Note tbe fol- 
lowing containment relationship (see Fig 2 i: 

• A switch contains ranis. 

• A card contains porK 

I, Construct each of the attributes lit. if make up Ihe fully 
distinguished name lor a raid in a switch. 



Mot switchNum C 
Mot. cardNum_C 



switcKHum( 100 } j 

cardUumt 10 ); 



This code fragment assigns switchnum to 100 and cardnum to 10, 

2. Construct the fully distinguished nana 1 for tbe port base 
managed object of the request. 

OVmotDnC dn; 

dn << switchNuin << cardKum; 

■3. Construct the list of attribute identifiers associated with 
the attribute values to be retrieved. 

OVmotAttldListC attr_ids; 

attr_ids << Mot_portStatus_id << 
Mot packOut_id << Mot_packetsIn id; 

4. Construct the base managed object identifier of t lie port 
associated with the request. Request processing to begin at 
the switch card with cardNum = 10 associated wit h the switch- 
Nun^ 1QD. 

OVmotBaseMoldC base_mo_id | 

Mot_switchCard_id , dn) ; 



fiO 
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5. Construct the filter This code fragment looks for in- 
stances where the values of packetsQu! and packetsln are 
greater than zero and the poftStatus is "IT," 

OVinctFilterC f ilter (Mot_portStatus_i i^- ! 

&&f Hoc_packetsOut_id > 
I !Kot_packetsIn_id > 3); 

mstrucl tht- Managed ( II - 

OVmotGfitArgC get_arg(base arc 

OVMOT IfIIi//Omit Access Control 
OVMQT_ CMI S 5YWC_BE5 T_EFF QRT , 
OVMOT_SCOPE_WHOLE_SUBTR£E , 
& filter, 
attr_ids ) ; 

// print to standard output 

cout << "C++ Constructed Get Argument" << 

get_arg << endl ? 

7. Build t lit- Xi )M CMIS-Get-Argument from the Managed Ob 
Toolkit C++ GET argument. 

OM_obj ect xoin_obiect; 

OVraotOXomStrC get_strm {XomWork space? -> 

q Work space ( ) ) ; 
get_strm << get_arg; 
xom_object = get_stnr».gAdoptXomPrivObj { ) ; 

8. Issue a standard XMP gel reum ^i 

mp_Etatus m mp_get req{ Session, 

MP DEFAULT CONTEXT, XOEl_object, 
tresult, &invoke_id) ; 

Without the Managed Object Too I kit -provided and Managed 
I fojecl Toolkit-generated classes the manager developer 
would be, faced with ihe challenge of constructing the XOM 

CMIS-GeL-Re quest objeel passed in the mp_get_reql } function, a 
task that could require al leas! six times as many lines of 

, Oil, 

Summary 

Developers who build telecommunications network manage- 
ment applications are implementing teage, complex solutions 
and leleronummiralinn s< i\ tee ptO% tders iel\ 0*1 iiiiernpcr- 

abiHtj standards to integrate and deploy these solutions in a 
heterogeneous networked environment Developing applica- 
tions thai communicate via the standard CMLs and CMTP 



i -ommunication interfaces has historical^ been an extremely 
complex and omcMonsuming task using the XMP/XOM APIs* 
The HP Open View Managed * HbjeCi Toolkit offers the dcvel- 

r significant assistance in this task by helping to trans- 
form a GDMi 1 specification into an executable, extensible 
agent application and providing an intuitive C++ interface 
for implementing agent behaviors and manager applications. 
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A Software Toolkit for Developing 
Telecommunications Application 
Components 



To be effective, application developers must understand the data 
available to their applications, the operations required to access the data r 
and the steps required to turn their understanding into an implementation. 
A prototype development environment has been built that helps the 
developer explore and understand the data in the Management 
Information Base (MIB) and construct and deploy pieces of TMN 
management applications. 

by Alasdair D. Cox 



Telecommunications mi work operators own ihc largest 
distributed computing systems in the world. Their netwo] ks 
carry enormous volumes t it traffic, much of which is highly 
valuable. Maintaining service is essential* The penalties for 
failure are great, and not just financial — emergency services 
arid some air traffic control transmissions use the same lole- 
phone network. Not surprisingly, network operators h&ve 

considerable systems ami network management nerds. 

The ability to provide new services is becoming vital in Ihe 
telecommunications business. Speed and Ilex ibi lily are key 
requirements, nol only of tbe initial implementation and its 
deployment, but also of the management systems that ensure 
thai Service continues to operate efficiently. The rapid devel- 
opment ul'eilW live management systems is Therefore a major 
concern 

The applications that telecommunications companies use to 
manage their equipment, networks, and services they pro- 
vide ar@ known as ojieratiatts support st/sirins, Q% ( tSS r An 
established network operator will have hundreds of existing 
applications and a contiiniing need to develop more as their 
systems and technologies change. 

The development of new applications in the Telecommunica- 
tions Management Network ! (TMN) area is still carried out 
wilh the aid of a C or C++ compiler. Tire developer must 
understand ihe data lhai is available to the application, the 
operations lhal can be performed to reach it, and thr applica- 
tion program interfaces (APIs) and tools available lo support 
those operations. 

HP Open \ i* Jm products provide support in a number of 
these areas. The GDM< I Modeling Toolsei (page IU helps 
the application developer understand the kind of data that 
is stored in the TMN world. The Open View Distributed Man 
agement platfonn (page 6) provides standard APIs rhai the 
developer can use to send i MIP [Common Management 
Tnfonnation Protocol j messages to die data. The Managed 
( Object Toolkit (page 52 ) provides further support to the t - - 
programmer, 



hi diis paper we describe :i prototype development environ- 
ment thai addresses some of tin i demands of application 
development in Ihe iHerommumrations world. This proto- 
type helps the user explore the available management data 
and make enough sense of it so that the user can construct 
and deploy pieces of management applications. 

Background 

Tbe Telecommunications Management Network is mi attempt 
lo standardize the management ol lelrcr nn mo ideations net- 
works. li consists of a set of existing and evolving recommen- 
dations from the International Telecommunications Union's 
Telecommunications Standardization Sector, known as the 
ITU-T.- These recommendations are based on a number of 
previous recommendations on Open Systems Interconnection 
(OSI} systems management, now adopted cLs international 
standards. 3 

Tlie OSI systems management standard proposes a Manage- 
ment Information Base (MIB J; 1 which is a collection of data 
necessaiy fur managing a network. This data is organized 
hierarchically and related by containment . The data is in the 
form of Objects, called managed objects, which are defined 
by the Guidelines for the Definition of Managed ( )bje< is 

The Guidelines fot the Definition of Managed Objects, or 
I ! ! MO, is the language used to define the structure and some 
of the relationships between managed objects. Thr GDMO 
definition is in the form of templates) used to define man- 
aged object classes (classes in s land aid object-oriented ter- 
minology), attributes [instance variables), actions ( methods). 
notifications {events ihat can he emitted bv objects), and 
name bint lings, which specify the ways in which objects can 
be related by contain mem in the MIB. See the article on 
page 13 for more about GDMO. 

The Common Management Information Service (CMIS)*' is 
used to interact with the MIB, and the Common Management 
Information Protocol I CMIPr is the way service mes^ag 
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are encoded for transmission between TMN management 
applications and the MIB. 

The available services include getting information from 
managed objects, changing their values, making method 
calls, and creating and deleting managed objects. In addition, 
managed objects can emit events. 

The Development Environment 

e that leiet onmiunieation management, applications 
of the future will be composed of a number of large-grained, 
distributed objects. We call these objects applicai 

Application components ram managed 

objects in that, at their am] represent 

logical and physical parts of a network. Applicatii >n compo- 
nents, on the other hand, are pieces of the system that man- 
ages the network and the services nmning on the network, 
and they may use, manipulate, and create managed objects 
as I hey work. 

Some components will Uv speriaHztid fora particular man- 
agement function while others will be of a more general 
nature and may provide services to more than one applica- 
tion. Applications will need access to data in a number of 
si Hirers, mc hiding other applications, traditional databases, 
and ilte MIB. 

We believe that the parts of the application that act as data 
bridges will be split into components, each capable of sup- 
porting transactions to a data source. Since our intention is 
bo support the development of telecommunication manage- 
ment applications, we decided to focus on the construct ion 
of application components that interact with data, and thus 
we have concentrated on (he TMN MIB, 

We have built a prototype development environment, thai 
includes three tooLs that operate together to support the de- 
velopmenl 111*- cycle of application components (see Fig. 1). 



In the initial stages of using the prototype, this means pro- 
viding aid in understanding the problem and progressing 
through to enabling the implementation, testing, and deploy- 
tnent of the solution. By taking this approach we believe the 
development process for application components can be 
greatly improved 

Alth< mgh the process is likely to be iterative, the basic - 
ping an application component using the TM\ 
pe environment shown in Fig. 1 are: 

• Navigation through and exploration of the MIB using the 
MIB br&wser to build an understanding of die data and the 

.n is used 

• Prototyping CM1S operations using the 

which helps to expand or verify the developers understand- 
ing (The results of executing these operations may be fed 
hack Into the browser to aid navigation,) 
Sn >ring operations away for future reuse or as documenta- 
tion aids 

• Construction of fragments of application functionality from 
a iiumher of operations using the application compon 

e&it&r 

• Deployment of the completed components as distributed 
CORBA* (Common Object Request Brake* Architecture) or 

* >LK i < )hjeet Linking and Embedding) objects or as source 
code for inclusion in libraries or directly into applications. 

The use of a common underlying arcMtecturaJ framework is 
a major reason why the prototype appears and behaves as 
an integrated development environmenl rather dtan as a set 
of standalone Hints This framework is discussed later in this 
article. 

• COftBA is from the Object Management Gmup (QMGj arid OLE 15 from Mien. 



Distributed Applications 




Fig. L Prototype telop 

meni >-\\- ronmenl 
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Fig. 2.niji| hi 1i--i > n:- fcllB 

browser shoeing a cached 

Ofttte r i « . 1 1 . i lj. ■ . I .I i.', ts in the MIB. 



MIB Browser 

The MB Browser provides the user with a graphical view of 

the MIB (see Fig. 2). By interacting with and manipulating 

iew. the user is able to navigate through the MIB lo 
explore the structure mid content of the data stored in its 
managed ohjeets. 

The view shown to the user is a cached subset of the man- 
aged objects that exisl in the MIB. The contents of this cache 
are built up as the user navigates through the MIB. A number 
nt simple operations are provided for this navigation, each 
causing a CMIS sendee request 10 be sent to the MIB. The 
replies to this request, which can vary from none to very 
many, are used lo update the cache and hence the view pre- 
sented to the user. 

The browser uses metadata to add meaning to the presenta- 
tion and to help the user navigate. For example, the names 
of managed object classes and attributes and (he del aits of 
attribute values are presented to the user as words, rather 
if i. in as the numbers that the underlying infrastructure uses. 
In addition, the browser is Somel lines able to advise the user 
in advance when a navigational operation is guaranteed to 



find nothing new. This decision is arrived at by using meta- 
data liial describes the ways in which the MIB can be orga- 
ui zed. The design of the MIB browser, including how the 
cache and metadata fit in, is shown in Fig. 3. 

Tne MIB browser Is useful to application developers and 
operations staff who understand the network and how \\ \> 
managed. It is also useful as an educational aid for training 
the entire staff lis main benefit is that it is not necessary to 
understand the technical details of a particular area to use 
the browser successfully, hi fact, we find that it helps users 
to increase their understanding of the network. 

Navigation by CMIS 

The MIB browser provides five predefined CMIS operatic ma 
which can be used to retrieve data from the MIB, The user is 
shielded from the execution details of CMIS operations by 
I he user interface. 

Three of the CMIS operations (expand fully, expand one 
level and expand by class) are used to discover the struc- 
ture of the MIB. The result of executing them is a set of 
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managed object names. The MIB bn i face pre- 

ihem as nodes on ihe tree displayed 10 the user. 

A fourth operation (all attributes) is used I Hie de- 

tails of a managed object. These details, or attribute values, 
of the manage*! object are stored hi Ihe bn che. 

Finally, t he fifth op i find Old 

ill the man 

about which we know onh the name 

We decided a$j king the structure-Sndu 

also discover ihe contents of the managed objects thej 

encountered, even though this would have reduced 

nth operation. There were two reas ms forthe 
decision: perf ormance and size It is not usually possible to 
[nviiji ; how many responses will be returned from executing 
an operation. For example, a lafge area of the MIB may lie 
within the scope oi an operation, possibly containing several 
thousand objects. Since the nature of the underlying GMIP 
protocol means that each object discovery results in the 
transmission of an asynchror* >ns message to the browser, U 
an operation requested the contents of eaeh managed obj. 
the size of each message would increase greatly and perfor- 
mance would be severek affected. In addition, the user is 
probably not interested in the details of mosi discovered 
objects. Knowing bow they are organized is often what 
matters. So the browse does not need to store Ihe details of 
■ managed object 

We realized that we could let the user decide which man 
aged objects had mien'Mim" contents, so we provided a gel 
of navigationaJ operations mid a drill-down operation, for 
(lie user tdexeoite appropriated 

Tbe following sections describe the navigation operations in 

detail, and Kiu. I shows I he values assigned to ihe 
fields in t'MIS GET requests for each nf ihe operations The 
article 6h page &2 provides nmiv information aboul ' mis 
get requests 

Expand Fully. This is the erodes! navigationaJ operation. It 
discovers all toe managed objects below a specified position 

cables the use* to see greater derail about a managed 



in the MIB. Tl < . d object and then 

presses the expand fully button on the browser window. The 
class and name nf the selected managed object provide the 
context for thi* operation. These values a* 
base manage* ^ass and instance fields of the reu 

Expand One Level, This is a safer operation than expand fully 
in that it can be used w 2 id fully would he inappro- 

priu l all the managed objects below 

expand 01 
ooryl immediatJ uon. 

In MIB-sneak. it finds all ihe managed objects contained by 
the base object, in computer-speak, it finds the children. 

Expand by Class- In diis < operation the user i^ presented with 

lanaged object classes thai 1 ssiblj 

lia\ 1 s below the selected position in Ihe MIB. This 

list is computed from the metadata (described below 1 The 
usei ran select ihe managed object classes of interest or 
scan 1 tu- list and choose likelv candidates. Prior knowledge 
is helpful bat noi essentia!. The choices are used to parame- 
terize the request. 

AH Attributes. This drill-down operation targets a single man- 
aged object thai was discovered by an earlier navigation. 
The values nf all ihe object's attributes are obtained. 

Find Class. This operation can be invoked on a managed ob- 
ject whose existence and name have been inferred from the 
results of an earlier operation, but Whose class is unknown. 

Operation De finer 

The MIB browser provides the USea with a small number of 

ways to construe! GlflS service requests- While d as is an 
advantage in tenus of ease of use ii can appear limiting to 
users wiih a need for selective mirnmation. To Chose with a 
greatej understanding of the area (ie,, the protocols and 
information models used) the operation del'incr give-, full 
flexibility in ih< construction of (MIS requests. < >peraft 
di fined ihis way can be used co-extend fche browser's reper- 
toire/The design for the operation deSner is shown in Fig. ">. 

As ihe name implies, the operal ion definer helps the user 
specify an operation to be performed on the MIH. ( >n<> 
spertjieaiinii is complied, riu- operation can be seni as 
sen ice request and the corresponding results dan be shown 
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to Ute user using an operation viewer, which presents infor- 
mation in a way that is similar to the MIB browser. The user 
< cii l examine the results, and if necessary, modify the opera- 
tion and reissue it. This cycle can continue until die user is 
satisfict 3 w it h I he operation. 

The results obtained by executing an operation can be added 
to the MIB browser to expand die vuu ii presents of the 
JVITrX In (his case, the operation definer can be seen as a 
powerful navigational tool that augments the basic browser 

Alternatively, the real benefit of the operation definer might 
be the operation itself, rather than the results of executing it 
once. The results returned will be useful because ihey can 
help prove that an operation works correctly. The user 
might want to store such an operation so that it can be used 
again. The operation definer maintains a repository for this 
purpose. By adding to this repository, the user can build up 
a toolbox of useful operations, similar to the way a system 
administrator builds up a library of shell scripts. 

For an operation to be executable, all aspects of its specifi- 
cation must be fixed. The operation definer picks up the 
starting point, which is the base mail aged objects name and 
(lass, from the browser context. All other asprcis of an oper- 
ation are defined by the user. Once this is done, I he operation 
can be tested and its definition refined until the user is satis- 
fied with it If l he fiiushed operation ts going to be used again : 
it is likely that the user will want it to be made more general- 
purpose. A stored operation can be made more general- 
purpose by specifying that some aspects of it become para- 
rsuicrized. meaning that each lime il is used the values of 
those parameters must be supplied. This allows the effect of 
the operation to be tailored to the context in which it is 
applied. In this way, for example, it becomes possible for an 
operation defined on a particular named network element to 
be applied to arty netw r ork element by supplying the appro- 
priate name and type information. 



Application Component Editor 

As stated earlier, we expect that future telecommunications 
applications will be made up of a number of large-grained, 
distributed objects. We call the objects application compo- 
nents. Some application components will communicate with 
data sources, incl tiding the MIB* lo obtain the information 
that other components will use lo perform management 
functions. We decided to concentrate out efforts on support- 
ing the development of application components that interact 
with the MIB. They play a more constrained role that is belter 
suited to automation, and the data they interact with is 
described by a standard form of metadata. A window dump 
from the application component editor shown in Fig. 6. 

An application component has four parts: 
Kufry points that make up the visible interface of a compo- 
nent (Other party of an application make calls to this inter- 
face to use a component ) 

i Operations that interact with the MIB and issue CMLS 
service requests and receive results 

1 Support functions, or scripts, that tie together the operations 
to implement the required functionality 

1 Test In net ions, some of wiiich test individual operations and 
some Of which lest the whole component. 

As shown in Fig. 7, the application component editor uses 
the operation defmer's repository. Operations stored in the 
repository can be selected for inclusion in components. 
They are translated into source code and t like a method, will 
perform the same operations when they are executed. The 
fields that are identified as parameters when the operation 
is stored can be treated as formal parameters lo the method 
hi addition, simple test functions arc automatically generated 
that test the operation with its original parameter values. 
The results obtained from running the test functions are 
presented to the developer in the same style as the MIB 
browser 
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Fig. 6. Output from the application 
ponent editor 



Although source code generation is nol strictly necessaiyj 
the ability to generate source code helps make the tools 
acceptable to the traditional telecommunications < liSS 
{operations support systems) developer market. 

The component editor is not restricted to editing new and 
existing components, fan also provides help in deployment 
There are several ways in which a completed component 
ran be made available for inclusion in an application, such 
as: 
• ■ AsaCORBAohje. i 
MmQlE/CQMtil 



*j\sa fragment of application source code for direct 
inclusion in larger application programs 

• As a library routine that can be linked into a number of 
applications 

• As p;ut of i he implementation of a managed object class's 
run-time behavior, 

We have concentrated on the first option. The signature edi- 
tor shown in Fig. 7 can be used to define formal signal u re > 
for entry points, usingASNJ types for the parameters and 
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results. This information 'm fcheil available id t hi - l]>L(!nler 

far c Definition Language) generator whieli produces equiva- 

Jem I i HnjAIDLijiiuiai ts using a standard translatnm 
algorithm,* : " These interfaces help Eh© developer towards 
deployment of application components as ( '< jRHA objects. 
A similar process would enable their distribution as ( >LK 
objects. 

The prototype application component edter generates SmalJ 
talk source code. la feet, we used IIP Distributed Smalltalk 1 " 
in automate the entire process of deploying application 
components as CORBA objects- Although Smalltalk is in- 
creaslnglj being osed farprodud development, it is usually 
restricted to research and prototyping work, A fulh Qedged 
to<»i would have to generate G prC+-h 

.Architectural Framework 

Fig, 8 shows the architectural framework upon which the 
three prototype loots (t he MfB browser, the operation de- 
fitter, mid the application component editor) are I mill . By 
building on top of this framework we wi re able to increase 
commonality in implementation, appearance, and behavior 
among the tools. 

Graphical Presentation 

All the prototypes jjete implemented in VisualWnrks Small 
talk, which meant we were able In use i is interface con- 
sl i in linn loots to develop Hie dialog boxes, menus, lists, and 
buttons llial make up most of the tools* iuier laces. In addi- 
tion, because Smalltalk is an object-oriented language, we 
could subclass interfaces and specialize t lie in for particular 
tasks. For example. Mare are several browser-type interfaces 
used by all three tools in different ways. These were not 
implemented independently. Instead, we implemented I he 
common features in a superclass, which was inherited from 
the supplied Visual Works r lassos* and created subclasses 
that became the browser and viewers for displaying the 
results of operations and test fund ions. In this way the 
three louls share a common look and feel because much of 
the Code is common 6b Ihem all Fig. 9 shows the inhcritanee 
hierarchy. 

The managed objects in die MIR are organized into a tree 
culled a rutttiiintrfrttt trn because die tree's edges ropre- 
senl a containment relationship. This reflects the equipment- 
oriented origins of the QSI systems management standards. 



Graphical Pudental ion 



Services 




CM IS Services 



Generating 






HP OpenView 
Distributed Management 



Fig. 8. Tlii' ..if j hi i-i '..i. n i. i i|i- iinvp protuty] 



68 Onobtr IS06 lU-w U'W Vi\i-ki\n\ Jminiat 






OperatioEi 

Viewer 






Fijtj. j}« Inheritance hierarchy of thi graphic ii pn sentatlon classes 

For example, networks contain equipment such as multi- 
plexers, uhieh contain circuit boards which in turn contain 
software. The JVILB browser enables users to navigate 
through the containment tree. It seemed natural to pivsini ;i 
view of the discovered containment tree and allow ibe user 
lo interact with it via buttons and menu selections. These 
i ip unions cause the browser «<■ execute (.'MIS operations lo 
extend Uie browser in Uie way the user directs. The browser 
shows a view of the tree as it Is discovered during a browsing 
session. We fell thai users would not see the larger picture if 
they focused only on one managed object ai a time or vvni 1 
presented with only a view of the path through the iree in 
thai object This larger picture often provides the context 
thai helps the user umU 'island the smaller picture. 

One lesson we learned from this prototyping experience is 
that more flexibility is necessary when presenilis informa- 
tion to the user. It is possible to discover quickly many hun- 
dreds or thousands of managed objects using the browser. 
This is generally more than the user wants lo deal wilh. 
Currently we advise the user to retrace steps jSfrtd iry again, 
applying more constraints to the search, hi the future u e will 
help the user with ways in reduce the clutter on the screen 
rather than put the responsibility on the user to figure out 
how to reduce it 

Metadata Services 

Many different types of metadata arc used by the tools that 
make up the M1B browser, including: 

* GDMO. w hich describes the kinds of data that can be stored 
in the MIBanil how it can be Stmt lured 

* ASN.l. which describes die basic data types that can be 
stored 

* IDL, which the application component edit or generates 
from the signal ure of the components 1 external entry points 

* Descriptions of how an operation should be parameterized 

* Descriptions of each application component. 

The tools obtain the GFDMO and ASN.l metadata via the HP 
OpenView metadata services. The metadata is stored in a 
repository mid can be queried by all of the tools. Some 
added services me implemented. Kor example, when the 
user wants to find objects Of a particular class or classes 
that are below a selected object in the Mill the allPossibleSub- 
□rdinate Classes service provides a list of the classes that il 
makes sense to allow the user in select from. This h 
often much shorter than the list of all km own managed 
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object classes, making it quicker and perform the 

action. 

The ( MIS requests and confirmations thai flow between the 
browser and the MIB use the GMIP protocol The infonnation 

Mil in the itmeric. For example, while the 

user wants to refer t« > the nefwori downstreainConneC' 

Pointer attribute, and iheintemammtngSourcB. speech, locked, 
anil Sunday dai theCMIP protocol will 

the numerical values ! 00 12 31000 3 1 }, | it 13 3101 

1 iata services perform tl 
sensitive translations automatically 11 1 both di> 

The MIB Cache 

The MIB cache n attains 1 >f the managed objects con- 

tained in the MIB This subset is built up in the cache as the 
user navigates through the MIB while using the MIB browser 
< operations used to handle this navigation result in responses 

sent from the Mill A r e s pon se equates to a single 
managed object involved in r he operation Some respon — 
Indicate errors and others return data. Bach data-bearing 
response contains die name and class of the responding 
managed object and possihly some addirii »na1 data, such as 
the values of attribui 1 a 

The tools parse the results and store the values m the MJB 

cache. This reflects what has been learned about the Mill hv 
tin' tools. The cache can be preloaded r seeded 1 on startup, 
which allows the browser to provide an initial context 
When the MIB browser or similar viewers present a picture 
of the MIB, i hey are really presenting views of information 
in the MIB cache 

CM IS Sen ices 

The CMIS services enable the tools to issue multiple ^rn-hm 
nous 01 asynchronous < Mis requests and receive mull iple 
responses to each request We built these services on Small- 
talk's support for multiple tin end execution and sync hit) 
nizaliou. 

Smalltalk classes that represent CMIS requests and connr- 
mations «rere defined A request object can be submitted to 
the t 'MIS sen ices component, causing the operation thai it 
represents to he executed. A number of confirmations will 
later in- received and a corrnrmarion object will be created 
For each confirmation, These confirmations are then sent to 
iiit Smalltalk process that made the request 

IIP Open View Distributed Management Platform 
The tools conned loan intermediary program called the 
CMIS interpreter, which in turn uses the HPOpenVie^ 
] iisirihtiiinu Managmerrt Platform as 1 he distribution mecha- 
nism and communications provider* The < Mis interpreter 
uses open Views standard V HM/XMP APIs to generate, 
send, receive, and parse < Mis requests and confirmations, 
t MuinninicniiMn between the tools and the CMIS interpreter 
is via an ASCII language, which is liken symbolic form of 

I MIS 

This arrangement provides us with the power of a symbolic, 
1 ,!i|. ciorienied Language for rapid developmeiM while still 
enabling us to make use of the communication Facilities of 
the I IP i *pen\ 'iew 1 jm platform, which is designed to work 
with C and Cm clients, 



\s\.l Representation 

The representation of ASV I types and values is important 
to all the major architectural components. Valises are passed 
to and from the (Mis sen b d in the MIB cache and 

displayed In ■ 'miponenT. ASN.l 

the metadata 1 : bed 

ah*. 

Conclusion 

ironmeru 

dial aids the coiLsiniction of telecommunications management 
applications- It is made up of three tools that together ad- 
leveiopment life cycle, from in- 
vestigation of the problem to the deployment ofthe solution, 

In choosing to address application components that interact 
w nil the TMN MIB, we deliberately focused on a well-defined 
subset of the overall application development area We 
then able i<> build tools that partially automate the task. We 
believe trus automation could greatly increase developer 
productivity. The tools 1 usefulness is not restricted 10 the 
development of applications. The MIB browser, combined 
ions and compon ents bull t using the Other 
loots, is a powerful environment for exploring, understand- 
ing, and troubleshooting the Mil!. 
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Business Process Flow Management 
and its Application in the 
Telecommunications Management 
Network 



HP OpenPIVt is an open, enterprise-capable, object-oriented business 
process flow management system that manages business activities 
supporting complex enterprise processes in a distributed heterogeneous 
computing environment. It is a middleware service that represents a 
substantial evolution from traditional workflow technologies. 

by Ming-Cltlen Shan T James W. Davis, Weimin Du, and Qiming Chen 



Business pr< u-ess reengineeriug is emerging as one of the 
crucial business strategies of I lie 1990s. Business process 
recngmeering is I ho fundamental rethinking and reimple- 
ment at ion of business processes to achieve nevor-beiore- 
possibic tevfcls of qualityj i -ost. throughput, and service* This 
is especially significant in an era of workforce downsizing 
and greater demands for Shortened time lo umrkol ami taster 
customer response. The need for business process reengi- 
neering is pervasive. Organizations are currently engaging in 
business process reenginecring in many domains, including 
financial services, telecom sen ices, healthcare services. 
customer order fulfillment, manufacturing procedure auto- 
mation, mid electronic commerce. 

Wliile business process reengineertog provides a business 
management eoncepl. business process flow management 
( BPFM ) soft w are — o r i n < ) i e ii< : curate 1 y t tuiti flint m t v — j ) ro- 
vides I lie enabling technologies for business process reengi- 
neerkig lo support flexible solutions for the management of 
enter] i \\ se-wMe operations, ineltn I i i ig: 

• Process flow control, automation, and monitoring 

* Resource allocation, authorization, and authentication 

► Task initialization and data exchange 

► End-t o-en< I coi 1 1 n 1 1 i 1 1 i i ation and security. 

BPFM is more than just a technology, It offers an overall 
environment and approach to unifying, automating, and 
measuring business processes. In addition, BPFM is not a 
technology supporting only business process reengirnvriug 
It can be used to manage existing uonautomated legacy 
processes— what is often called ^paving the cow paths.'' 

Business Process Flow Manage men I System 
Al I he enterprise level, the process u> be managed can be 
very complex, spanning several organizations with multiple 
Steps being performed in parallel. In such cases, a BPFM 
system can act as die superstructure lhat ties together dis- 
parate systems whose business purposes are interconnected. 

A BPFM system provides procedural automation of a busi- 
ness process by managing the sequence of process activities 



and the invocation of appropriate human, instrument, or 
computer resources associated with various activity slips, 
1 1 involves the high-level specification of Hows, and provides 
i he < »porational glue and environment support for managing 
and aufomaling the flows, recovering from failures, and en- 
forcing consistency. A BPFM sysiem also enforces various 
administrative policies associated with resources and work. 

The structure and flow of a business process managed by a 
11PFM system can be preplanned or ad hoc. In the case of a 
liPFM system managing the process of providing telecom- 
munications service, the flow of t lie process is ad hoc and 
depends on the services required by a customer, However 
certain aspects of die process will be preplanned and delib- 
erately structured. For instance, regardless of t lie individual 
services required by a customer, the process always origi- 
nates in the sales depari moul and is always ends in the billing 
department 

Typically, a BPFM system: 

• Provides a method for defining and managing I be flow of a 
business process. 

• Supports the definition of resources and tbeir attributes. 

• Assigns resources to work. 

• Determine which next steps will be executed within a 
business process and when they wiD be executed. 

• Ensures that the business process flow continues until 
pro) jer termination. 

Nut i ties resources about pending worl^i 

• Enforces administrative policies such as access control 

• tracks execution and supports user inquiry of status. 

i Provides history information in tbe form of an audit Trail for 
completed business processes. 

• Collects staiislu ;il data for process and resource bottle- 
neck analysis, flow optimization, and automatic workload 
balancing. 

HP OpenPM 

HP OpenPM is an open, enl cerise-capable, objeci-orirtirrd 
BPFM system developed ai HP Laboratories to manage 
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business - supporting convex enterprise processes 

in a distributed he ms computing environment- ft i> 

a mjAfleware service ttotrepres i 'Manual evolution 

from traditional workflow tedmoiog 

Given the trend towards open systems and standaj- 
BPF with and rake advantage 

dards .inmercial products foi manic* 

Hon. legacy application ing. 

In particular, thr ( >\ BA (the £3 men! 

ion ( >1>j< r Broker Archil ihe 

IXE (the < Jptii Software Foundations Distributed 
Computing Environment), IIP Open View, and IS< > I >M 
(International Standards f 'r^anizaiion Open Systems Inter- 
connection \ KW technologies are expected to play an 
important role in the developmenl of BPFM systems. IIP 
> tpn,p\i provides a generic framework and a i oat] 

ervfces for business process flow management nshiL 
above-mentioned standard technologies, w it li emphasis on 
performance, availability, scalability, and system cobusti 

Basically, IIP * Jpml'M pi&ti 

An open system adherirtg to the 0* >KBA communications 
infrastructure and providing a WfMC (Workflow Manage- 
ment Coalition) .standard interface. 
High performance as a result of optimized database 
and commitment 

KuVnivc management with an IIP Open View-based system 
management environment. 

A COir^rehenave solution for business reengineering 
including an extensive sel of products. 



The overall architecture of an HI 
pitted in Fig. I The care is ihe HP* tpcuPM engine, which 
suprx - for business process definition, 

business process execution, business ? lonitoring. 

nee and policy management, and business - if 
management 

■ess is specified via the process definition 
interface. An instance of the business process can be 
start t d, or con t rolled via the | $ ion 

interface. Status informal 11 -nd 

load information of tht neried via the 

process monitoring interface 15te resource and policy man- 
nent interface is used to allocate, at run time, execution 

trees to a task, according to (he policies defined by the 
organization (including authorization and authentication j 
and the availability of the resources, Interaction with the 
external world (e.g., the invocation of an application, the 
control of an instrument, or the deliver) of a work order n> 

»ms e-mail intiay i \a ilu* task * if the business object 
management inter- 

HP OpenPM Process Model 

A business process isa description of tin -sequencing, tim- 
ing, dependency, data, physical agent allocation, busnn 
.li- and organization policy enforcement reiuiireim-uTsof 
business activities needed to emcl v\urk. 

An MY ' OpenPM process is a directed graph consisting of a 
sel o1 nodes connected by arcs. Fig. 2 shows an example of 
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the user interface. There are two kinds of Yiodes^w&fk nodes 
and ralr np$e$ — ami two kin Ms ol'kuvs— thrift trrf arcs and 
rest ft rocs, A work node lias ;il iimsi one inward arc and one 
or more outward arcs. A rule node can have 1 any number of 
inward and outward arcs. 

Work nodes represent activities to be performed external to 
the IIP OpenPM engine. These activities include authoriza- 
tion, resource allocation, rite execution of business ohjecls, 
run 1 1 he provision of input data for the business objects and 
output data from them. Rule nodes represent processing 
interna] to the IIP OpenPM engine. This processing includes 
decisions of what nodes should execute next, the generation 
6j reeeptton of events, and Simple data manipulation. 

A work node Ls a place holder for a /process ffcfiriitj. whieh 
is a logical representation of a piece of work contributing 
towards the accomplishment of a process. A process actiuu 
Ls mapped In (he invocation of an operation on business 
objects during ihe execution of the process. Each process 
activity can represent a manual operan<m l.\ a unman or a 
< nmputerizable task to execute legacy applications, access 
databases, com ml instrumentation, sense events in the 
external world, or even effect physical changes. A process 
activity definition includes aforward activity and optionally. 



a compensation activity a caned activity) a resource man- 
agement activity) timeout and deadline information, and 
input and output dam, 

Rule nodes are used to specify process flows 1 1 1 ^ i r arc more 
complex than a simple sequence. A rule Language is used in 
program the rule node decision. When executed, a rule node 
del ermines which outward arcs to fire, based on the sUilus 
passed along the inward arcs, the time at whieh each inward 
arc is fired, and The process-relevant data associated with 
the process instance. 

Rule nodes are also used to support ©vents. A rule node can 
raise events when certain conditions stte met as defined by 
the rules, and an even: can activate rule nodes lhai have 
subscribed to reeeive the event 

Forward arcs represent the normal execution flow of process 
activities and form a directed a< yclie graph. Successful com- 
pletion of a node at the source end of a forward arc triggers 
the starting of the node at the destination end of the forward 
arc. 

Reset ares are used lo support repetitions or explore alter- 
natives in a business process. Reset arcs differ from forward 
arcs in that they reach backwards in the process graph. 
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Rule nodes are executed each time any inward arc fires. 
Work nodes h imt When the inward art- 

is fired on a work node in the initial state, the work node 
changes its slate to fired and performs its associated activity. 
When the inward arc is Gred on a work node in the Tired 
: lint* is done. 

A reset arc, together with the Forward arcs betweei 

lina source, forms a loop. When traversed, a n 

arc causes ail nodes within its Resetting a 

fired work node changes it - 

can be reexecuted. Re- i >rk node cancels 

the current execution of ihe corresponding process activity 

and change its state in nfttai 

Associated with each business process, there 
data template defined b} the business process designer. The 
process data template is used by ust*rs to pro\ide initial data 
for the creation of process instances At run tinvi-, based on 
the process data template and read/write lists of activities 
defined in a business process. HP OpenPM will generate a 
case j'ttfkt-1 for each process instance to facilitate data pass- 
ing between activities and the HP OpenPM engine, 

HP OpenPM Process Execution 

Kiu 3 shows a simplified version of the component structure 
of the IIP OpenPM engine, which coordinates the overall 



ntion flow of business processes. It functions as a highly 
reliable, log-based state machine. The HP OpenPM engine 
interfaces with external environments through a uniform 
CORBA4>ased transport interface, independent of the actual 

physical dispatch of the requests. 

The HP OpewPM engine launches business process instances 
in respnj For each instance, the HP 

OpenPM entr *hrough the nodes according 

• d in its business process definition. For work 
nodes, the HP < OpenPM engine will execute the associated 
process < forward i activity. For rule nodes, the HP OpenPM 
engine will evaluate the rules and jjerform the rule actions 
when the rule conditions are met. 

Each node transition is durably logged to facilitate forward 
rolling of incompleted business processes at system rest art 
time in the event of a system failure, or to facilitate a sup- 
port activity compensation process In Cti€ c&se Of a business 
arris ir> failure, hi addition, IIP OpenPM allows flexibh' 
specification of compensation scopes and actions ("e.g., 
compensation activity or cancel activity) to support various 
application needs. 

In HP OpenPM. different versions of similar business pro- 
cesses an- supported by the engine under lite concept of a 
process group. The user can designate a particular version 
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as the default to be used when no specific 1 version is re- 
quested ul the lime a business process instance is created. 

To monitor the progress of running business activities and 
support system management, the IIP OpenPW engine main- 
tains a comprehensive log (if all events and provides a native 
interface as well as SNMPAMIP gateways to facilitate hid - 
unirion with the IIP Open View environment The formats 
and contents of the logged information can be customized to 
support specific application needs. 

HP OpenPM Business Objects 

IIPOpenPM has to interact wilh business arti\ hies sup- 
ported by various implementations encountered in real life. 
These can range from manual handling by humans to auto- 
mated processes executed by computers. An infrastructure 
is nee fled to enable the effective management and invoca- 
tion of these business activities 

I distributed Object technologies have become the primary 
infrasinirtun 1 lor enieiprise-seale distributed computing. 
Among them, the OMG (Object Management Group) CORBA 
[Common Objed Request Broker Ar chi t ec tur e ) t echno logy 
has [Ken developed to support interoperability for applica- 
tion integral ion. 

Based on CORBA technology, in HP OpcnPM an abstraction 
called a business object is built to encapsulate whatever 
piece of work each process activity has to accomplish. 
The wrapping code provides an IDL (Inierlare Definition 
Language) interface and the business objects are catalogued 
in the IIPOpenPM business object library, 

A business object, as defined by the OMG, is a representation 
of something active in the business domain, including its 
business name and definition, attributes, behavior, and con- 
st rail its, II provides a uniform way to encapsulate legacy 
systems and applications, and a direct mapping, in under- 
standable business terms, between the business model and 
the possibly sophist iealed operational procedures of the 
business pro cess sy ste n r 

By representing these process activities in business objects, 
new business processes can be quickly created by assem- 
bling business objects to describe business processes. The 



business object library avoids repetitive coding in tailor the 
business activity implementation to each individual business 

process. 

HP OpenPM Resource and Policy Management 

A resource is a person, computer process, m machine ihai 
can be used to accomplish a iask> A resource has a name 
and various attributes defining its characteristic -s. sin h as 
job code, skill set, organization unit, and availability, 

A policy is a set of rules that det ermines how resources are 
related to tasks within a BPFM system. One common use is 
Tot lask assignment. Policies can be used to specify which 
resource, under which role, is eligible or available to per- 
form a task. Policies are also used to ensure proper autho- 
rization and authentication 

In HP ( >penPM r the mapping between the business nelivily 
(task) specified in a business process and the business Object 
( resource} lu be invoked is performed by the resource nitfit- 
Og&r during run time as pari of the execution of the business 
activity, IIPOpenPM allows multiple resource managers to 
be used to resolve a single resource assignment request; 
each resolves the request at a different level within an Orgs 
nidation. 

HP OpenPM Worklist and Application Data Handlers 
Two optional components that can be added into the IIP 
( JpenPM environment to facilitate the execution of business 
processes are the trorklisf handler and the ®$pli£Q$i&n duta 
l}fni(ff<T{*ri.> Fig. I). Both components are designed lo en- 
hance the scalability of IIP OpenPM systems. 

The worklisl handler supports both t'nifhn'-inish and rUrut- 
fiifl modes to provide more freedom in task assignment. 
In addition, the worklist handler can be used to support the 
concept of integration on demand. Based on the task 
performer's profile, the worklist handler determines and 
launches a Specific environment tor an activity at run lime, 
rather than bard-wiring it into Ihe process definitions. 

The application data handler supports the separation of 
application-specific data and process-relevant data to reduce 
the amount of data flow T over the network. It also provides 
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the preparation facility for application-specific data to 
remove the burden of database access from activity per- 
formers. 



Business 

Management 

Layer 



Sarvfet 
Crtatron 



SOTlftCf 

ActivaTvon 



Sendee 

Assurance 



HP OpenPM Security 

In todays business environments, security must be imple- 
mented enterprise-wide. The security 1 service developed by 
the OMG provides authentication and encryption for HP 
e\ ent eavesdropping and forgery. The HP 
OpenPM irrfrastmcture components can identity each other 
and vouch for the credentials of end-user campon* 

BPFM in the Telecommunications .Management 
Network 

The Telecommunications Management \ i t h - >i k | TMN" ) 
decried by the International Telecommunications Union is 
changing the way operations support systems and business 
support systems solutions are being developed. The TMN 
architecture separates layers of functionality and provides 
access by elements in any one layer to am element in the 
layer immediately below. Before the introduction of Ehe 
TMN model operations support systems and busim 
port, systems solutions were isolated from each other and 
em ltd sifjt interoperate. 

The IIP UpenYiew Distributed Management platform sup- 
ports the realization of TMN operations support systems and 
business sup poit systems solutions loi ihe TMN element 
management layer and network management layer ( see the 
article on page t> for a description of the TMN layers). Still 
needed is a middleware service supporting the service man- 
agement layer and even the business management layer of 
the TMN model. This need offers a great opportunity for 
BJ *FM added value. The next section presents an example of 
this support. 

Ar rhe service management layer the BPFM process enabling 
framework is required to be able tr>: 

• Support reengineering and transformation processes for 
strategic operations support systems and business support 
systems. 

• Integrate existing operational environinenis Jo form an 
enterprise hub for service management and provisioning. 

• Deploy new management services as rapidly as possible 

• M oni t or an d itk * as ur e \ y r o cesse s 

• Tune processes to benefit from experience. 

•■ Automate processes to reduce execution time. 

The overall deployment of BPFM technology in the TMN 
environment is depicted in Fig. 5. 

SONET Configuration Management Prototype 

Based on an HP ' 'pi I'M system, we built a prototype to 
demonstrate the application of BPFM technology in ihe 
specific domain of SONET i Synchronous ( tpiiral Network t 
configuration management. The prototype was a joint pioi 
eci between HP Laboratories In Bristol, England and Palo 

Alto. California tn demonstrate the middleware lerlmologies 

required to automate the processes supporting the configura- 
tion management of a SONET telecommunications network. 

The scenario iJemuMsii ah'd by this prototype consists of the 
provision of a new VC4/VC12 path for customers, It goes 
through several eiiffereni steps for this operation search for 

a new unite, negotiate the sen ice level agreement (SI A) 
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with the customer, configure the new path, and finally, up- 
date tlie SLA for this customer. The IIP OpenPM process 
definition supporting the process of providing tills new 
S( )NET data path is sketched in Fig. ft 

Searching for and configuring a new path hi SONET are 
complex processes requiring a lot of interaction with the 
Si >NKT \1IP> i Management Information Base) and network 
elements, This type of operation is a source of errors when 
it is performed manually hy an operator as a set of Individual 
in i correlated activities. 

In ihe prototype, such complex operations as searching and 
configuring new paths are handled a.s business processes 
and automated by an HP OpenPM engine in an environment 
interacting with IIP < >penView DM and Oracle DBMS appli- 
cations. 

Depending upon the changing business needs, a customer 

can request iio add ok <io»p communis Mkon paths between 
certain endpniuis \n a private rhinai network \ P\ Nj, hi F ri' 
OpenPM, these services $bx\ be modeled as business pro- 
iv^rs to be executed by the service provider. Adding a new 
path maj consisl of the following activities and decision 
points: 

1. Retrieve the customer's profile frewrti file customer datdr 
base foi rastoiner-PVN^pecific informatiorL 

2. Locate the closest add-drop multiplexers (ADMs) to the 
endpoints, based on the information St n d in the SONET 
physical configuration database. 

3* Check whether fiber connections exist between the end- 
points and the two end-ADMs. 

4. II not. issue Li request for. an engineer in go onsite and 
physically conned the endpoints to the end- ADMs. After ihe 
establishment of the connection, the process continues on 
to step ■"> and an independent subprocess is initialed to watch 

for resource changes. 

r i. Find valid routes between end-At)M& Fins requires access 
to i lie routing [able in the SL\ database to determine whether 
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any valid routes exist between the two end- A I >Ms. Either a 
list of ADMs is returned signifying the ADMs that must be 
configured to realize ihe route, or Ji No Route Found" is re- 
turned. For a returned list of ADMs, this activity will then 
use the IIP Open View I >M facility agent to collect port infor- 
mation stored in the MIH lo determine the available ports 
between the ADMs thai are fibervd together ant I can be used 
to enable the path. 

6. Check network element (NE) capabilities. For an ADM in 
the route, this activity uses die IIP Open View DM NE agent 
lo access the MIB in formal ion to determine whether a VC4 
cross-connection can lie set up in the ADM between the 
selected ports of the ADM, This activity has to be executed 
for each ADM in the route. During steps 5 and 6 ? if any addi- 
tional resources become available, HP OpenPM cancels any 
currently running activity and starts the process over from 
step 5 to consider these newly available resources, 

7. Get customer's approval of the selected configuration. 
Once a suitable path is identified, the customer will review 
the offer, induing available date, charges, quality of sendees 
(QoS), and so on. Depending upon the business factors (e.g., 
cheapest service wanted), the customer may request that a 
new search be initiated, that is, loop back to step 5 to find 
another valid rouir. 

8. Configure the selected route, This activity is responsible 
for setting up the cross-connect it his in each ADM by invok- 
ing the HP Open View DM NE agent and updating the SLA 
database. 
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HP OpenView Agent Tester Toolkit 

In developing HP OpenView agents, a major challenge is to develop and 
test both the agent and the manager simultaneously To fill this need, the 
HP OpenView Agent Tester Toolkit generates tests and allows the 
developer to execute these tests individual ly or as a set. 

b\ Paul A. Stoecker 



IIP OpenView agents ran be created by telecommunications 
network management developers either by using tools or by 
writing the code directly. The tools available include the 
i T ji\io Mftfh'fhiti 7 Ni*/ I .;;<. which helps in the 

design and specification of network management objects 
using the « rDM< > language, and (he IIP Managed Object 
Toolkit (see page 52), which accepts GDM< documents and 
produces C*m code to implement a default agent thai meets 
those specifications. Whether the developer builds an agent 
using these tools i hi w rites the code by hand, one of the major 
challenges is to develop and test both cm Is of the commu- 
nications link simultaneously — the Qg&tt controlling the 
managed device and the manager thai sends requests to the 
agent and i rceives the responses. To fill this need, the new, 
HP ( >penYiew Agent Tester Toolkit generates teats and 
allows the developer to execute these tests individually or 
as a set 

The Role of an Agent 

An agent program enables other programs, called mana.-. 
in control physical and logical resources, Bjtamples of re- 
sources that are controlled b\ agents are telephone sfwitcWhg 
equipment and phone sei •■• \a databases From a centralized 
location, a telephone service provider can use automated 
processes lo monitor the performance of the communica- 
tions lines, reroute traffic m necessary, and maintain ihe 
business and accounting records, [lecau.se the communica- 
tion protocol between managers and agents has been stan- 
dardized, a wide area nelwork of multivendor equipment 
can be efficiently controlled bom a small number of central 
locations 

The resources being monitored and controlled sute modeled 

Ejects railed \naiuiged object dosses Managed object 
. lasses are logical groupings of the attributes, events, and 
actions associated with a resource, AGDMOspet ification 
defines ihe various managed object classes that make up 
the interface b> the resource. Instances of these classes are 
called into existence by sending a create request. The attri- 
bute values tor an instance are accessed by issuing set and 

get requests lo Change or retrieve the attribute values, re- 
spectively, < Hher message types remove an object instance, 
allow die agent to notify interested patties of an asynchro- 
nous change, or cause tin* agent m perform some agreed- 
upon activity, 

' GO MO »$ the ISO, j International Standards ft ■ ■ 

■acts 



A collection of managed object instances and their relatii m 
sliips is called the containment tree. Subobjects are lugicalk 
contained or grouped within other ob 1 depicts 

portion ■»! a containment tree. Each of the boxes in Fig. l 
represents an object Instance The label in each in>\ identi- 
fies the object class of that instance, f&t example, m Fig, h 
a fibei optic network is composed of iwo network elements 
In one of (hose network elements, the n generator and nitilri- 
plexer sections are shown. 

One of the attributes within each of ihe contained object 
instances is designated as Ihe distinguishing aWib^te, and 
the value of this attribute is used to uniquely distinguish that 

nee t'r« mi -aW of its siblings. The containment nee is 
used to uniquely identify, or name, an object instance. An 
object instance anywhere in ihe containment iree is identified 
by specifying ihe distinguishing attribute and its value from 
ihe top of the tee down to the desired instance. The con- 
catenation of all of the distinguishing attributes along this 

naming path is caller! \hv fully distinguished name* In Kig, I, 
the fully distinguished name lor the multiplexer section 
would consist of the sequence networkfd - "netl \elemenild s 5. 

muxld = 56. 




Fig, 1. ,\ iisiUati ii !" i il in - 
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Agent Development 

The Managed Object Toolkit ftves an encirnious amount Ot 
work hy handling all ol the overhead of de< -oiling and vali- 
dating incoming requests, locating the selected object in- 
stance within the eontainmenl fcflee, and invoking an appro- 
priate C++ method on I he selected object. However, die 
attribute values thai are set or retrieved by the initial Man- 
aged < )hjeet Toolkit output are only internal representations. 
I h< developer is responsible for filling in empty C++ stubs 
to make the internal aliribltte values reflect the state Of 
external physical devices. During this coding process, u is 
helpful to simulate ihf requests that will eventually be sent 
by a manager. 

The Agent Tester Toolkit performs this task in two 
First, it creates lest requests from the GDMO specification. 
Second, n transmits these requests 0V^tJiefl#WiH&tol3fie 
agent and receives the responses. During the development 
phase, these test files can be sent individually and the re- 
sponses viewed interactively. As each agent operation is 
implemented, the associated test requests can be added to a 
fcesl suite. The accumulated tests can then be run in a batch 
mode to check that previously implemented functionality 
still works properly. Fig, 2 depicts the sequence of steps 
needed to generate and send the test requests, and shows 
how the Agent Tester Toolkit relates to other development 
tools. 

Running the Agent Tester 

The components of 1 he Agent Tester Toolkit are command- 
lim tools that are invoked in a straight .forward way. Fur 
example, ovatgen -t /tests gdma mib reads the GDMO description 
in the file gdma.mib and generates a set of test requests Stored 
In Hies under the directory /tests. Next, tests for a particular 
object instance can be sent to the agent as follows: 

5 ovatrun -i 
>create 

>getall 

>mytest 

> delete 

The -i option to ovatrun specifies the interactive mode, in 
which the user can type the name of a test iile in response to 
the > prompt and the response from the agent is displayed 
immediately f shown by the dots above). 

The test Eles represent CMS (Common Management Infor- 
mation Service, ISO/IEC P6§5) operations, such as create, 
set, get. and so on, and are stored in a directory layout that 



minors The organization of the agents containment tn-<-. 
with each directory named 1 ted managed object 

class name. At, each level in the containment tree, test files 
are generated that create an object instance, get all attributes, 
and delete the instance. If there are changeable attributes, 
tests are also generated that set those attributes to new 
values ami retrieve the changed attributes, hi addition, files 
are generated that test attribute groups and actions. Docu- 
mentation files describe ihe Object identifiers used in the 
tests aud optional features i ailed conditioTial packages. 

Each test request is written in a format (ailed ASN.l value 
notation, which is a standardized format described in TSO 
aud ITl-T documents {K82-J and OQ& respectively). ASN.l 
(Abstract Syntax Notation One) is a notation for expressing 
the types of the ai tributes and operations. Fnv example, a 
test tile that contains a get request to retrieve (he current 
values of several attributes might appear as: 

Get Argument { 

— pasBwordEntryManagedObj ectClass 

baseManagedQbjectClass {1 3 6 1 U 119 81}, 
baseManagedObjectlnstance diet inguiabedName : 



{ 



« 



i 



— passwordRootName 
attributeType (13 6 1 4 111 9 
attributeValue Mod .Root Syntax 



-- loginNaine 

attributeType {13 6 14 1119 
attributeValue Mod . LoginSyntax 



29} , 



21}, 
r paul" 



attr. 


LbuteldLiat { 




-- 


password 




{1 


3 6 1 4 1 11 


9 22), 


-- 


userlD 




{1 


3 6 1 4 1 11 


9 23} 



In this example, the first word. GetArgument T announces the 
ASNJ type whose value follows, A GetArgument is a struc- 
tured type, and in this example its fields are baseManagedQb- 
jectClass. baseManagedObjectinstance. ami attribute- (dList, Lines 
beginning with -- are comments inserted by the Agent Tester 
Toolkit generator to help the reader identify the various 
object identifiers (Gtps), which are strings of digits £e*g«, 
{\ 3 6 1 4 1 11 9 23}} that uniquely identify attributes, r. lasses, and 
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other fields. Returning to the GetArgumem request when sent 
by the Agent Tester Toolkit it asks the agent to return the 
current value of the password and user ID attributes of an 
< ih ji ss passwo rd Entry Man agetJO&jectC lass. The particular 

an object instance passwordRooiName 
= D, which in turn contains the desired subobjeet loginName - 
paul. A typical res| " 

G^t Result { 

managedObject Class (13614 1 II 9 81}, 
manage dOb j set Instance distinguishedName . 



i 






attributeType {13 6 14 111929}, 
attribute Value Mod. Root Syntax 



attributeType {1 3 6 1 4 1 11 9 21}, 
at t r i bu t e Va lue Mod • Log i nSyn t ax " pau 1 J 



cur rent Time "19960327 14 5 13 5 % 
attributeList { 
( 

attributeld {1 3 6 1 4 1 11 9 22}, 
attribute Value Mod.PasswordSyntax "secret" 
i« 
{ 

attributeld {1 3 6 1 4 1 11 9 23}, 
attributeValue Mod*UserIDSyntax 44 6 3 



This response returns the requested class and Instance infor- 
mation, and reports thai the values Of the two requested at- 
hibules password and userlD were secret and 4463, respectively 

It is also useful to gather as much informal ion as possible 
when error conditions exist. For example, if we try to querj 
an objed thai doesn't exist, an error is returned, letting us 
know what aspect ofthe nnjuesi was rejected: 

$ ova t run -i 

> get bad 

— Error: No such object instance 

Objectlnstance distinguishedName : { 

{ 



t 



}, 
I 



attributeType {13 6 14 1 11 9 29}, 
attributeValue Mod* Root Syntax 



attributeType {136 14 1119 21} , 
attributeValue Mod*LoginSyntax "joe" 



Test files are ordinate u-\r Hes, and customized tests cm be 
crafted using the generated tests as guides. Several support- 
ing toote are included in theAgenl Tester TooUdI 



Batch Testing 

I portions of the agent have been developed and the 
- art* working individually* it is good practice- to run the 
tests and cheek fch 1 1 at* automated fashion, This is 

useful to monftor existing behavior of an agent as new code 
is added of u ■ tie able to repeal the testing pn toes as new 
versions of the agent are de . r the agent is ported to 

new hardware platforms. To this end, the Agent Tester Tool- 
kit s ran program can execute a sequence of ti 
The command is ovatrun without die -i option: 

$ cd /tests 
$ o vat run 

This causes the list offcl --fault test director tile, 

batchjist, to be rim and the reap* rases sfc fl ed Alter all ti 
have been run, the responses are compared against a set of 
known-good results, and summary statastai epared in 

a log file, reporting the number of tests run, passed, and 
failed. The known-good result files are generally prepared 
by co; ual response tiles that have been manually 

verified. A utility tool is provided that copies result files into 
e as known-good comparison files \s part of the copying 
process. ibis utility removes lines ihai contain the current 
time, since this would needlessly cause comparison failures 
m future test suite runs. 

The test director tile in lis simplest form contains the nanus 
of die lest files and the order in which 'hey are n> be sent. 
Opti< .rial commands in this file allow Tor more complex situ- 
ations. For example, ISO standard inin-i-i identifies situa- 
tions (object creation, objed deletion, and attribute value 
change] in which the ageni should emit an event so lhat all 
interested managers i an maintain a synchronized view ol 
i hi agent'sstafee. Toaierl rite Agent Tester Toolkit toexpeel 
hcilh a response tO Olie Of its own create, delete, or set re- 
quests and the resulting eye&t emitted by the agent, the pair 
Command can In* Used. For example, the command pair pass- 
word/create sends the requesl command contained in the file 
password/create and then receives both the conllrmntioii of 
the request and a notification that the creation has occurred. 
Similarly, if an isolated event is expected- the event command 
can precede the name of a file with which rim arriving eveni 

will tie compared. Other commands, sneh as a shefl escape 

user eummand. allow customized testing. 
For example, a shell escape allows the test designer to send 
ual to the agent process to triggei sunn- behavior, such 
as the sending of an event This simulates the behavior of 
the agent in actual operation where some asynchron 
condition nughl cause the events while still allowing the teal 
process to receive a predictable stream of responses footri tht 

agent. < Miter commands allow Oner control OVerthe testing 

process. For example, a timeout value can he set thai on, 
in lis hou long the tester will wait for a response before 
ah< n i Ing any single test. An example of a test director file 
\\ irli some of these commands included is as follows 

tt Comment b begin with the '#' character 

| The following files are regular tests to get 

# the attributes in the already-created 

# Root Managed Object Class 
root ZpassFileMOC/get all 

# Some of the next tests expect both a response 
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# and an event 

pair root/passFileMOC/passEntryMOC/create 
root/passFileMOC/passEntryMOC/getall 

pair root/passFileMOC/pasBEntryMOC/set 

root/passFileMOC/paBBEntryMOC/get 

pair roo t /pas 6 FileMOC/paesEntryMOC/ delete 

# Set the timeout to 30 seconds 
timeout 3 

# Send a UNIX signal that triggers an event 

I kill SIGINT ${AGENT_PID) 

# Receive the event 

event root /pas sFileMOC/ pa sssEntryltfOC/ event 1 

Finer Control of t he Generation Process 

\ powerful feature of the object -oriented design methodology 
is thai the standards bodies have invested much energy into 
constructing managed object class building blocks. A side- 
effect, however, is that in most cases ihe standard documents 
from whirl i specific agents inherit contain far more definitions 
than are needed for that agent. In the case of the Managed 
( >bjed Too] Id I, Ihis causes needless code to be generated, 
producing a larger agent than is required. To counteract this 
effect, the Managed Object Toolkit allows developers ro 
specify a subsel of ihe managed Object classes, so that code 
is generated only for that stibsel. The Agent Tester Toolkit 
accepts die same subset speedier, and tests are generated 
only for thai subset. 

In some cases, greater control over the nature of the gener- 
ated tests is needed than simply selecting a subset of man- 
aged object classes. An example is the containment tree 
example given in Kig, 1 that began with a network object as 
the root node. The GDMO description uf a network class 
might allow {as ir docs in ITU-T Recommendation M.3100) 
that network to be decomposed into subnet works and sub- 
subnetworks, and so on. To allow the test designers lo specify- 
how many levels of decomposition the agent is expecting, a 
containment tree specification file can be prowled lo the 
tesi generator. This specification file is formatted like an 
outline, with the level of indentation indicating how deeply 
under lht> moi node each class is contained. For example, 
the containment Iree in Fig. I would be depleted: 

network 

> element 

> > regenerator 

> > multiplexer 

(Only one of the element nodes is shown. It will he ex- 
plained laler how to im hide both circuit branches.) 

if I he agent is expecting the network level to be expanded 
into network and subnetwork levels, this change can be in- 
corporated in the specification file by introducing another 
network node and indenting its children by mi additional 
level: 

network 

> network 

> > element 

> > > regenerator 

> > > multiplexer 

This change adds an element lo the distinguished name (cor- 
responding to the subnetwork distinguishing attribute value) 
in each test file, so such containment changes have far- 



tea H ting effects. Making such i|i visions earl} in the specifu a 
tinn pha much work compared to adjusting nheady 

generated test files. 

As mentioned earlier, the tesls are placed in a UNIX directory 
structure that parallels Ihe containment tree structure, with 
each level named by its assoeialed managed object class 
name. In many cases, managed < inject class names can be 
lengthy, and a pathname to lower-level lesl cases COiupO* 'I 
of a sequence of those names can be unwieldy. For example, 
names such as tra ilTermrnatron PointB id irectiona I and connectionTer- 
rnJnationPointSource appear in the standards, and when several 
of these are joined (as is typically done when specifying 
containment relationships), the combination is hard to read. 
To p< jp u I a t e Ihe dir ec t ory structure w i 1 1 1 shorter, m ea j i in gful 
nanus, a ilelault heuristic is applied Ihat selects a lew letters 
Iron i each segment of a managed object class name. Vnr 
examples a file deep in the free described so far might be 
named netw/netw/elem/mu It/create. Alternatively, Ihe lesl devel- 
oper can override tins heuristic by specifying shorter mm us 
in an uplional field in the specification file: 

network (net) 

> network ( subnet ) 

> > element (NE) 

> > > regenerator (rs) 

> > > multiplexer (mux) 

Finally, the GDMO document duesifi specify actual attribute 
values, so the containment tree's distinguishing attributes 
have lu be supplied by the test designer. ( >nce again, much 
work is saved by specifying these early, rather than fixing 
tests after they are generated. These distinguishing til trib- 
utes can be assigned in the last optional field of the specifi- 
cation file: 

network (net) networkId="ftc" 

> network ( subnet J networkId="Bldgl" 

> > element (NE2) elementId-2 

> > element (NE5) element Id- 5 

> > > regenerator frs) rsld=4 

> > > multiplexer (mux) muxlD=56 

Note that by including the distinguishing attribute values, 
we can differentiate between the two element sibling 
branches. 

A supporting tool called ovatct reads GDMO files and pro- 
duces a skeleton specification file similar to the one above 
(using the same subset selection file as the Managed Object 
Toolkit, if provided), More meaningful abbreviations and 
attribute values can be noted in the specification file ami 
then used as an input to ihe lesl generator to guide the 
production pro r ess: 

ovatct gdmo,mib > apec file 

ovatgen -t /tests -f spec file gdmo + mib 

Summary 

Key design goals of Ihe Agent Tester Toolkit include sup- 
porting agent developers during the development and main- 
tenance phases, and confirming compliance In ihe GDMO 
specifications the agent is to implement Also important is 
the ability to generate lesis Herat iveiy for evolving designs, 
without tune-consuming configuration changes of the test 
engine itself Hie Agent Tester Toolkit complements other 
tools in the development life cycle. 
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Storage Management Solutions for 
Distributed Computing Environments 

Strategies for dealing with the vast amounts of data generated by today's 
information technology environments involve more than just larger and 
larger disk drives. They include the right combination of different storage 
devices to deal with offline, neariine, and online data storage and 
scalable management software, 

by Reiner Lonih. Kelly A. Emo, and Roy M. VanDoorn 



Storage management is East becoming one of the mosA im- 
portant issues information technology I IT) managers fece 
today. With data accumulating at enormous rates, and with 
end users demanding faster access to more inhumation. 
storage management has moved from an operation that was 
done only at night to a mission-critical concern that requires 
full-time attention, 

Storage management consists of all the activities related to 
the effective deployment, accessibility, and use of stored 
information across a computing intrasinicturc. Storage man- 
i tent involves several ma j< >r disciplinesj including backing 
up and restoring data, storing data online across multiple 
classes of storage devices such ;ls disks and tape* Mchivtag 
data for legal and historical pijrposes, and managing storage 
resources such as tape or optical media for optima] use. 
Managing flits*' storage disciplines lakes an effective enruhi- 
. i nidation, prnre^'s, and technologies to meet 
end-uses data availability expectations, 

In today's distributed computing environments, IT manaj 
m-ed consistent storage management strategies and pro- 
cesses across the enterprise In addition, storage manage- 
ment processes cannoi be separated from an Integrated net- 
work and system strategy. Therefore, IT managers need 
complete solutions thai integrate the various storag" 
airmen! components and technologies such as databases, 
file systems, storage peripherals, storage management apple 
cations, and network and system management 

In t lie past, storage management solutions have been propri- 
etary (mainframes) or piecemeal (early client/servei point 
products), with specific peripherals working only with spe- 
cific software and hardware. It was difficult to expand a 
solution to meei the demands of rapidly growing collections 
of data 

hi this article we will describe trends driving storage man- 
agement technology and the components that make up an 
ideal storage management solution Finally, we'll Introduce 
HP hardware and software products, services, and partners 

and describe how I hey work together providing storage 
solutions for our customers. 



Storage Management Ttends 

Traditionally, the task of storage management was done 
after work hours when the system could be brought down 
I. n storage management functions such as backup and 
archiving. Today, much more da I a is generated, and Storage 

management solutions need to provide much greater data 
a\uilui)ility and reliability, CompUcating storage management 
are variables thai determine data throughput and a i 
l hese variables include disk capacity, GPU, input/output 
channels, device speed, networks, and software (Fig. 1), 
New ways of transferring and storing large amounts of data 
without downtime have to be developed 

Probably the most important driving Factor in storage man- 
agement toda> is thai customers demand continuous acces- 
sibility to tmge amounts of data, very often in the terabyte 
range You can sec* ihis demand occurring in the increased 
use of the Internet and online services such as CompuServe 
;ihi America I inline, and in ihe emergence of rteia applica- 
tions such as imaging and multimedia In ihe past, data 

accessibility was a Tank simple process when mainframes 

were the primary storage devices and the onjy limitation 
mas disk size. Today, the a us w its to storage problems 
cannot be provided simply by totalling a bigger disk on a 
centra] server. 

\s ' ustomers reengineer then businesses, man\ are cho< «s 
iiig to migrate away front the mainframe via "mainframe 
downsizing " Mission-entu M applications are moving to 
open systems, and the management of client/server work- 
groups is being consolidated across LANs and WANs. An 
enormous amount of company-sensitive data, which used in 
be under central control and located in the data center, is 
now distributed and available mi the network \ Fig 2}. Pub- 
lished market numbers show that the average amount of 

distributed data has surpassed the average amount of data 
in the data center < Companies must begin viewing storage 

management as integral to their network and system man- 
agement solutions. 
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In addition to all the challenges raised by managing storage 
on distributed systems, FT managers must deal with the 
reality that the amount of data being stored is outstripping 
the network's capacity to handle it el linen I ly (Fig. 3), For 
example, a company might need to back np 100 Gbytes of 
data in an hour. As the storage staff looks for solutions, they 
see processor perfonnanre improving faster than disk per- 
formance, They also see die performance of both disks and 
processors outstripping the performance of the installed 
network infrastructure. At the rate network infrastructure is 
improving, it will be a huge challenge to catch up to proces- 
sor performance. 

If IT managers try to win this conies I wilh only the tradi- 
tional approach of centrally stored data, they will lose the 
storage manager neut race. Instead, today's storage manage- 
ment s olutions m ust al 1 o w dis trib ut ed sto rage i n ar m g c m cut 
lo be performed centrally, decentrally, or in a hybrid fashion, 
depending on a company s policies and needs. 

To solve the growing issue of storage management, they 
need to understand what constitutes a storage management 

solution- 
Storage Management Requirements 

The ideal storage management solution, which is made up of 
complementary software, systems, arid peripherals, is inte- 
grated, scalable, and modular, and allows the solution to he 
implemented in phases and expanded over time. A Hex i hie 
solution addresses both mission-eril icaJ enterprise-wide 
requirements and business-critical desktop needs, At the 
same time, this solution must be easy to use and robust, and 
must provide quick, reliable access to data. 

The fundamental requirement of any storage management 
system is to provide data accessibility to all users, regard- 
less of where and how the data is stored. To make data 
quickly accessible, yet store it efficiency, customers need a 
complete, integrated set of storage management functions, 



Fig* L Components In the- chain 
lint huvi-'jm itn|,:iri mi .;. , 
throughput, 

in* ludiug backup and recovery, archiving and retrieving, 
hierarchical storage management, and media management. 

hi addition, an enterprise-wide storage solution must allow 
various storage management applications and peripherals to 
manipulate and share media in a consistent manner. It must 
also provide an easy and standardized way lo access the 
various storage devices, library systems, and silos. Many 
companies are dedicating servers to specific tasks such as 
backup and restore servers or archival and retrieval servers. 
A storage solution must he optimized so data is stored and 
moved in the most efficient maimer. 

Other more generic services for storage management include 
a central policy definition and a single point of control.* 
Lights-out operation and unattended remote backup are also 
key to many storage management solutions.** Storage man 
agement solutions are most manageable when integrated 
into management systems such as HP Open View, which pro- 
vides integrated network and system management sendees 
dealing with monitoring, problem management, and configu- 
ration and change sei vices. 

Backup and Recovery' 

One of the most important needs in enterprise-wide storage 
is backup and recovery. Very early in a solution deployment, 
IT managers must establish a backup and recovery policy 
that provides the appropriate level of data Integrity. This 
policy must ensure that critical data can be completely and 
quickly recovered from a backup even in the event ®£% 
disaster. Equally critical is minimizing planned downtime, 
or completely avoiding downtime, to create a backup while 
keeping user applications up and runiung. 

' A central policy describes a SSI of features that allow an administrator id define policies about 
how distributed storage is to be managed from a central management console. For example, 
an administrator defines for a networked environment which data needs to be backed up, 
when it will be backed up. which device will be used foe backup, and so on. 

' In The iT community lights-out operation means thai art IT environment can run wittioul local 
operators or administrators 



82 Odofeer 3 &J6 Hewlett-Packard Jo 1 1 mal 



)Copr. 1949-1998 Hewlett-Packard Co. 



Regionally Distributed Systems 




Operating Systems 
Running un Servers 
and Workstations 



Data Center 



Distributed Client/Server Workgroup 



MVS 






Fig* 2. Decentralized storage managen i nl i • n mltt]$d toito $ti 



Archiving and Retrieving 

The main reason For implementing archival and retrieval 

solutions is the need to teep data long-term and guarantee 

retrieval when art ess is required, The (lain is typically 
copied onto a different medium such as tape or optical disk, 
while the original ropy is deleted firom magnetic disk 
Archived data Is not frequently accessed, but sophisticated 
retrieval mechanisms need to be available- In many cases, 




Loss Protection 

Space Mil n a gem en l 



Time 



Kitf, 3, Thevohime ofdata being stored is Qtf1 tripping the abllj 
,1 with ii. 



archiving (lata is required for legal or internal auditing pur- 
poses The archiving procedure includes storing data thai 

logically belongs togethci in long-term storage such as a 
finished project, a finished design, or a client record 

Hierarchical Storage Management 
Hierarchical storage management, <>i HSM. efficiently man- 
ages data stored on magnetic disks, optical disks, and tapes- 
Depending on tnsi versus performance requirements, data 

is kept un on iim m of the different storage hierarchy 

Is Miici migrated transparently among the storage media 
according torirstonier-definrd policies. An HNM system 
reduces ongoing storage configuration tasks, such as nuking 
data, manually between levels in the hierarchy and subse- 
quent management costs. It also eliminates frequent storage 
maintenance, such as manually archiving ivies onto tape to 
free disk spare, and it helps reduce the need to acquire 
more expensive media, such as magnetic disks, fur in In 
ummly accessed data For example, files are migrated from 
disk to tape or optical storage if they are not accessed for a 
certain time period. Statistical data about access patterns 
ean help to define the right migration policy AKo. keeping 
statistical data ahoiu migration patterns atul creating appro- 
priate reports will help bo implement the righi storage man 

agement policies for an organization. 
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Media Management 

Ml- Storage eeraces discussed above handle copying or 

moving data onto media or retrieving data I'nmi media 
Media management, winch keeps track oJ" removable media 
such as tapes or opt tea] devices, deals with the medium it- 
self and not with the dala on the medium. A media manage- 
ment system protects dala on the media and makes the 
media pools available to storage management applications. 
Typical media management functions include mouiil and 
unmount media, rotate media, and provide statistical infor- 
mation about t lie media. 

Most of today's backup, retrieval, archival, or HSM products 
have their own integrated media managemenl functionality 
dedicated to a specific product. Enterprise storage manage 
mriii solutions hmjiiuv generic media management services 
delivered in an integrated way, so that media use can be 
managed and optimized across applications and systems, 

Enterprise-Wide Storage Management 
IT departments also require consistent and effective man 
agement capabilities tor storage management across die 
enterprise environment, To provide these management 
sendees, a complete Storage solution must provide: 

■ A single point of control which is consolidated console 
management , including: 

( antral policy definition 
i entral monitoring and problem management 
( 'entral configuration of storage 
» Mult i vendor availabiLity and support 

Scalable, modular services 
• Integration with an industry-standard network and system 
managei nenl framework 

■ High availability of key storage management Components. 

HP Storage Management Solutions 

HP can offer many different solutions to an organization's 
storage needs because of die combined effort of major IIP 
business organizations in the areas of network and system 
management, storage peripherals, and UNIX" servers. 



However, each <u stumers needs foi nut 

Milimons. ;irv different. No one vendor Can provide a single 
solution for every environment. Rather than create a mono- 
lithic, proprietary solution, HP is working closely with third- 
parly partners and many diverse HP divisions to create an 
open, standardized environment in which many vendors can 
participate in creating solutions. 

HP Storage Management Software 

('entral to I IPs storage management offering is the software 
that Jinks all the other pieces of a storage management solu- 
tion together, HP's two leading storage management prod 
nets, IIP Open View < mimBack II and HP Open View Onini- 
Storage, are el i en l/server solutions that give IT managers 
the flexibility to manage distributed storage centrally and 
delegate management responsibility to distributed sites or 
departments, HP OiuniBack products address issues asso- 
ciated with data loss and protection, and HP OniuiSlorage 
products address issues associated with spare management. 

HP Open View Omni Back II. HP offers two backup solutions: 
HP Open View Omni Bark II for Workgroups, which provides 
an entry- level backup solution ideally suited for the work- 
group environment, and IIP Open View OnuriBackll, winch 
provides a comprehensive backup management solution to 
cower ail sizes of environments, including the whole enter- 
prise. 

The HP (mini Hack II architecture (Fig. 4) consists of three 
major pieces: 

Backup Manager. This module centrally administers and 
controls the backup environment. 

Backup [ >>■'■■ ice Servers. These servers run on the sysiem it. 
which the backup device is connected. A backup environ- 
ment can have many backup device servers. 
* Clients. All systems being backed up need a client to invoke 
I lie backup utilities. 

All three components can run on the same system or can be 
distributed. OmniBaek II has its own management interface 
and can be run inside or outside the HP ( ipenview manage- 
ment interface. 




J Backup Environment 



Fig. 4. The . i r' . ■ r i m i r 1 1 r 

and components for HP QpenMew 
iBack II 
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QnuiiRack II is a scalable and flexible solution. Through 
its policy-driven, cenirally managed, automated backup 

^abilities. OmniBack II reliably protects data distributed 
throughout the entire network. Easy-to-use backup and re- 

e functionality provides management for desktop PCs r«> 
UNIX-based business servers. In combination with HI' < >pen 
View IT « operations, administration and problem management 

the entire enterprise can be centrally 

thisticated media and device management combined with 
sup] lainframi 

make OnuiiBack U the ideal sol 

Increased uptime for application and database servers can 
be achieved through high-performance offline backup, re- 
tmirmg only a minimum of application downtime. This can 
be extended to L00% application avaflabi&t^ through online 
I iack up of business data, 

Tlie main features provided by OmniBack II include: 

• Network backup and recovery 

Supporl for a broad range of devices and libraries 

• Online backup of applications and databases such as 
SAP/RS, Oracle, and Sybase 

• Sophisticated media management 

• Support fqr major I'MX and PC platforms, including 
Windows NT 

• High-performance backup and recovi r> from multiple 
drives in parallel each running at Us full native throughput 
Integration with I MM ipenView IT/i rperatioris 

• Integration with I3F OpenView OmniStorage. MPs hierarchi- 
i ;aJ storage tnanagemeru solution. 

HP OpenView OmniBack II for Workgroups. < hum Rack II for 
Workgroups is a complete solution thai offers everything 

needed lot a low-adininisiration> automatic, unattended, and 

reliable network hack up iii id recovery solution 1( is targeted 
toward smaller mull i vendor computing environments with 
out dedicated administrators, OmniBack II Eoi Workgroups 
includes the following features: 

• Automated and reliable network file system backup and 

i Sophisticated and automated media management, auto- 
loader supporl 

< Supporl t"! all majO) t MX mid P< 'ptalforms 

• Easy-to-use intuitive graphical user Interface with many 
built-in browsers and selection lists. 

HP OpenView OmniStorage. ' OmniStorage is HP's hierarchical 
Storage management solution. [1 offers benefits ^ environ- 
ments where a significant amounl of data needs to be on- 
line, hut where n<it all of the data is frequently accessed 

OmniStorage provides high-capacity, eosl effective online 
ragebj supporting HP*s broad range of optica] librarii - 

and the newest tape libraries According (<► policies defined 

h> die customer, flies are automatically ami transparently 
migrated among the levels of storage hierarchy. 

Pit;, B shows a typical envtronmenl in which < hnnistorage 
Kins, The two main pieces of OmniStorage are the manager 
and lire clients. The mnnagei adnnnisiers and controls the 
storage environment, and die clients im ■< >ke ihe t >mni- 
Storage functions on behalf of users, 



Omni- . -fitly integrated with HP OpenView IT 

a dministr ation and problem 
management of multiple OmniStorage instaBaiiuas from a 
station console. OmniStorage also integrates 
w irji " tnmiBack H for automated backup and recovery of the 
HSM enviroiuucnr However; On can run 

standalone product, which allows -implement 

^e management in pha 

erformanc - fre~ 

mbsetofl .dditionally. Onmi- 

an he used for databases if thej are based on a file 
m and if major pails of the database, such as dectsii m 
support systems, are not frequently accessed 

:ll\, < ►mniStorage provides the following features: 

► Policy-driven automatic and transparent file migration 
Network migration for HIM X and Solaris operating 
systems 

► Additional multi vendor support through NFS 
Exceptional!} fasl rebuild capabilities in case of data loss 
l Configurable demigration strategy 

An fiival to \V< >RM \ write once, read many i disks 
» Integration with HP.i IpenView < tmniBaek II 
i Integration with HP IT/Operations 
i Support for data warehouse environments. 

HP OpenView Solutions 

HP ( >peu View's solutions at ttegy fur managing 

multivendor networks, systems, applications, and databases 
from the mainframe to the desktop IV. The IIP < ipenView 
portfolio and companies that provide network and system 
mana.U" Mien! solutions (solution partners) give IT managers 
the tools to control and manage all enterprise resources and 
devices centrally, while reducing the cost of systems opera- 
tions and administration. Besides ( trnruBack ami Omni- 
Storage, more than 250 IIP t rperiV!ew4>ased nianagemenj 
solutions from IIP and soh u ton partners integrate with a 
complete set of common management services to help 
customers improve service and reduce operation c ■• 



OmniStorage 

Chenl 




Tape Storage 

Fig. !$♦ The componei 
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i 'ouiiaj to the HP r )|„. r ,Vii w products is a user interface thai 
provides a focal point from which the FT staff can manage 
computer systems and network devices. All hough coatroJ \- 
cetitralized through tbe iuierbice, management functions can 
be distributed across tin* enterprise. More important, flexible, 
distributed interfaces allow several operators and adminis- 
trators ki hi* involved in the prm , s- ofiT management. 

As an importer! pan of ihe IIP Open View solutions frame- 
work, IIP Open View IT/( )p< rut inns provides ccnirnlUed 
operations and problem management wiih distributed intel- 
ligence across muliivendor platforms. With intelligent agents 
(managed nodes) installed throughout the enterprise^ IT/ 
Operations collects up-to-date, accurate information to pro- 
vide 2 1 ■ 7 (24 hours a day, seven days a week) uptime for 
miss ion -critical applications. IT/Operaikms-managed nodes 

gather information, message^ and monitoring values from a 
variety of sources, Filters and thresholds ensure that only 
relevani information is Forwarded to the centra] manage- 
ment system and presented to the responsible fT/Operations 

operators. 

HP and Third-Party Storage Peripherals 

The IIPHUOO supports mass Storage products that provide 
online, nearline. and offline storage capabilities. The pri- 
isur\ differentiator among these three categories of storage 

is access time. A Storage device is considered online when 
I he data access lime is a fraction of a second. Nearline slor- 

age devices usually access data in the range of a few seconds 
to a tew minutes. Offline storage devices lypicnlly require 
many minutes to hours to access data. Some offline storage 
Strategies that require retrieval from a storage vaiili may 
take days before the data is available Io Ihe user. 

HP and its partners can provide a wide variety of products 
to imri the individual needs of specific customer environ- 
ments- These products i an be mixed and combined with 

IIPs Storage management software to provide the needed 
tnd user solutions. 

Online Storage 

1 1 P i offers t wt > elassi ss of online mass si orage i >rt K I nets: 

siiigle-spiiidle disks and disk arrays. 

Single-Spindle Disks. Single-spindle disks offered by HP are 
either embedded in the host systems or provided externally 
within storage enclosures, These disks provide high-capacity, 
nonvolatile! fast-access mass storage. Single-spindle drives 
operate at 7200 rpm and are currendy available in capacities 
of \M'y i ibytes, 2. i « Kbytes, and 4.3 Gbytes as fast/wide dif- 
ferential drives. 

These new drives are available as embedded devices in ail of 
the HP 9000 servers, more than doubling the internal online 
Storage capacity. With the addition of ihe L'Mihyie drive, 
21.5 (i bytes of external online Murage capacity can now be 
housed in a single enclosure rack with up to L60Gbytes in a 
1 .^-meter-high cabinet. 

" disk platters uv a single son-idle 



HP External Storage Enclosures. HP offers two families of stor- 
age enclosures for online storage: the HP 6000 & SI mass 
storage family and the HP I unavailability storage system, 
HP's high-availability storage system is based on a package 
design I hat delivers flexibility and ease of use while providing 
Critical functionality to unci the needs of the enl erpiise. The 
Sj Stem | n ovides excellent availability, hot-plural il. | M iwer 
Supplies, final. )H»v\er( % mis. cooling fans, and hot-pluggable 

storage modules. 'Die subsystem connects io the sen er via 

dual SCSI buses, increasing reliability and enabling disk 

mirroring in the same enclosure; 

HP Disk Arrays. A disk array is a storage syslcm consisting of 
multiple disk drive met -nanisms under the command of an 
array controller that communicates wiih ihe host (Fi.gj>), J 
The key beuelii ol disk arrays Ls high data protection Arrays 
also provide high storage capacities, connectivity, and con 
Figuration flexibility. 

HP currently offers three primary disk array families associ- 
ated with the IIP 9000 business server product line. The first 
family is the IIP high availability disk arrays Model 10 and 
Model 20, which have a raw capacity of ri Io SO U bytes, sup- 
port RAID levels l and 5, and Hive dual and nonswappable 
controllers and redundant cooling and po^er. 

The second disk array offering is KMl's Syminetiix 3000. 
The Symmetrix 3000 is a high -performance integral ed-cache 
disk array designed for online storage. As such, the Symme- 
trix 3000 provides a high level of online performance, an 
Online capacity of up n> LI terabyte, and manageability and 
high availability to HP Q0O0 business servers. The result is a 
maiufinim -elnss daia storage solution thai is simple to man- 
age and is delivered in a high-performing, scalable, protected, 
and o j ) en archi t ec hue. 

The final disk array is the fault-tolerant, self-coniigiiring, 
high-performance HP disk array product with AutoRAID 
technology. The HP AuloRAlD disk array eliminates the 
need for system adrni nisi rat ors to understand RAID levels. 
h dynamically adapts to the system "s workload, thus opti- 
mizing foi ■performance and rust. Finally, it offers a raw 
capat ily of up to 21 gigabytes. 

RAID * ftedundaru Array of fndeperatent Disks. 
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Nearline Storage 

Most files and applications stored on hard disks are never 
used. Thus, the major benefit of hard disks — high-perfor- 
mance access- — is squandered on tiormani di* r 
tive environments would be i by a hierarchical 

storage management solution in which active data is stored 
on hard disk A >rmant or infrequ< I data is 

I offline or nearline in media such as 
al disks. 

HP SureStore Optical Storage Products. HP oflers a broad family 
nf optical disk drives, ranging in capacity from 40 Ghyles to 
1 rbytes, HP oflers multifunction magnetooprical drives 
with rewritable and WORM disks. A rewritable optical disk 
can be written up to 10 million times, A WORM disk can be 
written once hut cannot be erased or overwritten, adding a 
higher degree, of security, 

The main features of these nearline storage devices include: 

• Fast, near-hard -disk transfer and seek times 

• High capacity 

• Low risk — no disk crashes with optical disks 

• Online data availability on a random-access device 

• Online drive replacement— provides assurance that the 
opii«;ii system is persistent^ available 

• Removable media 

• Long life — provides more than 100 years of media life 
without maintenance \ 

Offline Storage 

HPs range 'offline storage products provide Jugh speeds 
and targe Capacities to meet the increasing demands of HP's 
high-performance workstations, network servers, and multi- 
user systems. HP has combined its reliable DAT products 
with an industn -leading autoloader design and networking 
software to give customers the flexibility they need for com 
plcir automated nvhw.rk backup. 2 

HP DAT Products. MP offers the latest DDS-2 tape drives in 
addition to IM )S and DBS DC drives. The new DDS-2 format, 
combined with IOmeter tapes, has a native mode capacity 
of i Gbytes, wtth data compression, customers can typic 1H3 
store s I rbytes on a single tape Pot unattended i n lights i mi 
operation, ;i six-cartridge autochanger is available Co rotate 
media for full and incremental backup and restore opera- 
tions. HP also supports * mm and Ql< tape drives. The main 
tares of these offline storage products include: 

• Unattended backup 

• High capacity with high reliability 

• Easy storage fa a fireproof safe according to indu 
standards 

■ DOS format can be interchanged with different 
manufacturers 1 tape i hives. 

Digital Linear Tape. IIP Wino sen ers support the HP l>U 
(digital linear tape) Ubrary 1 I*. This library consists of four 
Quantum DLT/looo drives, aceornmodatirtg48 2Q*Gbyte tape 
cartridges and providing greater cartridge capacity than the 
l u >S format The DLT/4000 is a (L64a cartridge streaming 
tape with a capacity of Hi 6byt.es per cartridge i wiih 2:1 
e< impression t, and ;i sustained transfer rate of:! Mhytes.'s. 
The [IP [>LT library 1/ is enables fast, unattended backup of 
over 100 Gbytes o1 data within the brief windows of time 
avaihible for backup in hit^h end < >LTP (online transaction 



processing) and decision support system environ mr 
(Fig 1 

The main features of digital linear tape include. 
■ A native-mode data transfer rate three times faster than 

competing technologies 
» Greater media and drive head longevity 

Soptt indexing for fast-streaming fite searches 

am I 
i Higher compression ratio for most dad 

p Driver support provided by HP for the IH-irac-k StorageTek 
tape drives (model _>e~ended I 

drives (model 479] 

3480/3490 Compatible Tape Subsystems, Libraries, and Silos. 
IIP provides driver support for lS-irack StorageTek tape 
ririv I 4781 ) and 36-track single-ended tape drives 

(Model 479 1 I A< !< lit n utalU StorageTek offers Timberline 
9490, a f.'ist wide implementation of the Model 4791 with 

ilbyte/s drive. These drives are compatible with all 
StorageTek silos, HP supports StnrutirTek silos, including 
one with a oOGVartridge capacity and !■" 1 1 art ridges I »< mr 
(upgradable to 1000 cartridges and 350 cari ridges/hour) and 
another with a GOOO-c art ridge capacity and 350 cartridges/ 
hour. Both connect to other devices and silos for easy 
growt \ i 

HP 9000 Business Servers 

Todays open systems foi critical business computing envi- 
ronments require three essential dements, First, they mu>i 
provide the storage management, data integrity, security, 

and nianageabuirj thai information technology managers 
have come to expect in running business-eritical applications 

rni centralized ]>rocessing systems. Second, they must pro- 
vide ^connectivity and compatibility with the growing base of 
PC desktop users. Finally, they must offer flexibility, perfor- 
mance scalability, and teehnieuJ innovation to keep up with 
emerging application demands, 

As the leading open systems platform. IIP 9000 business 
sen its offer the bene fits of all three elements in a single, 
unified. I MX based platform* 30h0 HP9006 servarplatfbrai 
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is able m support environments of all sizes, ranging from 
workgroups and replicated sites to the departments and 
data centers of large enterprises. For storage management, 

the IIP 9O0D business servers offer the following features; 
J hghry available and reliable systems environment 

* Excellent data movement management 

* A dedicated storage server architecture tbat is designed for 
optimal database and file management 

* Scalable from desktop to data center 

* Hundreds of partners thai ensure customizable solutions. 

Storage Solutions for the Enterprise 

To help understand how to plan a complete storage manage- 
ment solution, we haw looked at scenarios common to many 
companies struggling with storage management demands. 

In each of the following examples, we'll examine the needs 
specific to each environment and the needs of centralised 
storage management starling with small workgroups, and 
building up to the enterprise level Then w&& show Imw IIP 
and its partners can provide a unified solution. 

Independent Workgroups 

Many workgroups implement their own backup and rei-oven 
solutions. These solutions are typically managed by a part- 
time administrator- Major requirements for backup and re 
t -overy solutions include ease of use and automation. Omni- 
Uack II For Workgroups is the best backup and recovery 
product for independent workgroups. Combined with HP's 
Iow-cosl, high-performance business servers and I IPs DDS 

II device libraries, backup procedures can be automated and 
centrally controlled within the workgroup. < .limn Back II for 
Workgroups provides easy and fast restoration of files and 
the potential to expand the workgroup or even consolidate 

I II u hi] lie wor k g to u p $ 

Solution Elements. The Storage management solution from 
KP for independent workgroups includes: 

• IIP OmniBack II [or Workgroups, with easy-to-use backup 
mid recovery software for small environments 

* HP 9000 Class D and E business servers for backup 

o I IPs DOS II autoloader as a cost-effective tape library, 

Distributed Client/Server Workgroups 

As information technology departments consolidate work- 
group management, they need more centralized storage 
management for distributed, heterogeneous workgroups. 
Two main objectives of flits scenario are to increase end 
user productivity by providing homogeneous and powerful 
storages, mid in increase operator productivity 

through central control and administration of those storage 
services over the LAN. Significant savings can be achieved 
through intelligent resource sharing and reduction of opera- 
tional overhead. 

< mimliack II centrallv manages the complete backup and 
recovery process of large numbers of distributed workgroups 
by dividing large numbers of backup nodes into multiple 
manageable backup domains. Central control can he main- 
tained ai the enterprise console while delegating backup 
and recovery tasks to the individual end-user departments. 
OmniBack 11 can automate the complete backup process of 
distrib u te d c 1 ient/s erver w < i jr kgro up 1 -. 



In addition, data on sharer I file servers and on client disks 
grows dramatically. Migrating Infreouentlj accessed data 

onto different Storage media such as optical disks or uijics 
becomes an administrative nightmare. Omnifttorage helps to 
increase the online storage capacity of clients and servers 
while keeping storage administration costs under control 

Solution Elements. The storage management solution from 
IIP for distributed client /server workgroups includes: 

• Centrally controlled backup and recovery for heterogeneous 
workgroups with UinniBaek II 

• Automated backup based on HP's DDS II Autoloader or DLT 
libraries 

• HP JMMHi business servers used as reliable and high-perform- 
ing backup, restore, and I ISM servers. 

1 "nlimiled online slorage based on i anniStorage combined 
with HPs Optical or tape libraries 

• Sophisticated problem management with IIP IT/Operations 

Regional Distributed Systems and WAN Connect ions 

Companies wiih branch offices in the retail Or financial indus- 
tries, for example, often have regional distributed systems 
connected via WANs. FT departments for these companies 
n^vd to run the IT infrastructure of the branch offices with- 
out operators or administrators. Remote control and admin- 
istration of storage services over t be WAN are essential 

OmniRaek II defines each remote branch office as a backup 
domain with one or more local backup servers. The complete 
backup and recovery administration process and control 
Can be performed from a central console via WAN. By 
choosing the appropriate devices, with sufficient capacity 
for each of the rerrmt v offices, the backup and recovery pro- 
cess tor the branch offices can be performed remotely 

Solution Elements. For regionally distributed systems the 
storage management solution from IIP would include: 

• Central backup and recovery for' remote sites with Omni- 
Back II 

• HP EJ0O0 Class D and E business servers for reliable backup 
and re co v e i y a t 1 >r ane lies 

• HP's DBS II autoloader for automated tape handling 

• HP JT/Ope rat ions integration of OmniBack II for sophisti- 
cated central problem management. 

Data Center and Mainframe Downsizing 
When customers migrate from the mainframe to open sys- 
tems, they expect the same fund n malily ami scalability in 
storage services as they had with the main frame. The IT 
department is expected to continue to provide the same 
level of assurance that computer services are available, 
reliable, and secure. 

For example, a major multinational company using die 
IIP-I'X operating system wit It large SAP/R3 projects based 
on Oracle requires efficient, reliable, unattended automated 
backups mid restores. These backups are in the multiple 
terabyie-perweek range mid will move into 24 X 7(21 hours 
a day, 7 days a week ) operation. OmniBack II is a key part of 
the solution because it gives the customer online backup by 
integrating with either the SAP/R3 online utility or the 
Oracle database utility OmniBack II also integrates with 
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nYOperations. This customer has complete centralized man- 
agement of all backup sessions and devices with the option 
of managing a partially or fully distributed environment. 

Because of OmniBack lis modularity and integration with 
othef online backup ser h as thos* i by 

I Hade and Sybase, customers can configure OmniBack II 

pand n> match their growing infrastructures. Many 
customers also may choose to add I : rd 

to ensure high availability of stored data 

Solutions Elements 

Data centers needing high -end backup and restore are pre- 
sented with the Following storage management solutions 
from IIP: 

High degree of automation with OmniBack II and Storage- 
TeksTapeSiln 

High backup and restore performance using StorageTeks 
Tim berime tape drives 

High reliability through HP 9000 systems running the HP*1 \ 
operating system 

SAP/R3 online backup with OmniBack U integration 
Enterprise monitoring and problem management through 
HP IT/Operations integrated with OmniBack II 
Full consulting, from investigation through implementation, 
by I IPs professional consulting services 
HP Mi '-'"Scrvircfhiard. 

Data Warehousing: Scalable Storage Infrastructure 

Much of a company s data remains valuable but does not 
need in be online and available all die time. Typical Storage 
capacity requirements <>l dura warehouses range from tens 
of gigabytes to several terabytes. Storage managers need the 
ability to move this data cleanly from primary lo secondary 
storage and back to primary temporarily, as needed 

The combination pdfHFs business servers, magnetic disks, 
optical disks, and OmniStorage offer an ideal storage infra- 
structure for data warehouse environments. This solution 
offers efficient storage hardware costs and high scalability 
for targe storage capacities. 

The ideal rniiu between magnetic and optical capacity de 
pends oil environment Ratios in I he range of 1:8 to 1:10 1 1 ,e ., 



1 Gbyte of magnetic disk capacity assigned to & or 10 Q 
of optical capacity* liave been implemented - lly. 

Solution Elements, HP provides the following storage maiv 
uent solutions for data warehouses: 
i Automated data migration with OmniStorage 

* i inline access to secondary and ternary storage through 
HP's optical and tape libraries 

• High-perforniance data warehouse applications based on 
HP ssKandTtmaa 

Conclusion 

The ideal storage system would provide complete and inte- 
grated storage management functionality, smooth integration 
with multiple file systems and databases across a bn»;»- I 
of operating systems, and support for a large variety < if pi 
liberals to satisfy ibe needs q| 'different storage management 
applications. Preventing this ideal solution from occurring 
are a multitude pf nomine grated storage components fn m 
different vendors. This situation forces administrators to use 
single-unit solutions for storage management, which leads to 
redundant and inconsistent management environments 

The HP storage architecture offers a streamlined and unified 
interact inn among diverse storage components. This archi- 
tecture allows for customized solutions usmgptug-and-pLiY 
components and enables different storage components to 
interact consistently For example. HP's backup solutions 
are being integrated via AI'ls with databases such as I teffi !■ 
and Sybase, 
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jects. He received a BSEE degree in 1377 and an 
MSME degree in automatic controls m 1978, both 
from Stanford University. Before joining HR he worked 
at PG&E as a- computer applications engineer devel- 
oping computer control systems He also worked at 
the Sequoia Group on medical billing and information 
systems Prank was born in Hong Kong. He is married 
and has two children, a boy and a girl. He is a board 
member of his church and was recently on the execu- 
tive committee at his daughter's school. In his free 
time he enjoys playing tennis Music is his main 
hobby antf he plays flute, clarinet, and saxophone He 
also sings and directs a vocal ensemble at his church. 

Satya P. Mylavarabhatla 

Born in Visakbapatnam, 
India, Satya Mylavaranhatia 
received a bachelor of engi- 
neering degree in 19B3 from 
Andhra University in India 
He went on tD complete an 
MS degree in computer sci- 
ence from Louisiana State 
University in 1938. After 
graduating he joined HP's Information Software Divi- 
sion. He is currently the technical lead engineer do 




the HP DPE project in the Telecommunication Plat- 
form Division and is responsible for the HP DPE archi- 
tecture and evolution. He recently was responsible 
for the' HP DPE trader and node controller. Previously 
he was the lead engineer for SLVM (shared logical 
vofume management) on the HP-UX operating system. 
Before that, he was the lead engineer on virtual 
memory and storage management for the MPE/iX 
kernel. He is named as an inventor in a pending 
patent on a software-based disk-locking mechanism. 
Satya is married and living in California. 

Trong Nguyen 

Trong Nguyen is a member 
of the team responsible for 
the implementation of the 
core server complex on HP's 
broadband internet data 
system {BIDS! project. 
Recently, he contributed to 
the repository subsystem 
developed with the H? 
DbjertStore engine Trong received a BS degree in 
chemistry in 1979 from the University of Colorado in 
Boulder, Colorado and earned an MS degree in com- 
puter informatron science in 1981 from San Jose 
State Umversity. He joined HP's Optoelectronics 
Division (OED) in 1979, Initially at HP, he worked an 
process control and automated test equipment soft- 
ware for the OED gallium arsenide manufacturing 
process. He then worked on HP LAS/ 1000 and HP 
ChemServer/ 9000 at the Scientific Instruments 
Division He also worked on HP OpenODB at the 
Commercial System Division and on HP DPE while 
at the Telecommunication Platform Division, Trong ts 
professionally interested in distributed computing 
and object-oriented databases. He was born in Viet- 
nam, is married, and has three children In his free 
rime, he enjoys reading, camping, and fishing 
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Frank Quemada 

Ffarik Quesmada is a ux 
itant at HF 

sentry worked 

Management 

sing the HP Open - 
ient 
inn Ha received a BA 
degree in economi cs in 1973 from the University of 
Chicago and an MB A tyof 

m He worker at Anfw Andersen & Co s con- 
sulting group before joining HPs Corporate accounting 
systems In 1962 initially, Frank worked as a software 
engineer and application support engineer before 
providing consulting services, customer education, 
and HP DPE support. He has authored an Interex 
paper on information mtegra hon, which was pub- 
lished in Interact and HP Omni 
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Sujai Hajela 

Sujai Hajela is a pf 
R&D engineer at HPs Singa- 
pore Networks Operation 
He currently leads support- 
related activities and pro- 
vides product consultation 
and implementation services 
to key customers. Since 
v '^ coming, to HP in 1994. he 
has contributed to the design and development r the 
HP OpenView Fault Management Platform (FMP), 
particulady the mediation device He designed and 
implemented the message object used as a message 
container in the FMP and the encoding and decoding 
librarres tor information transfer between tin 
ation device anrt the CMP server During FMP installa- 
tions at key customer locations, he ass isle d with 
modeling ol the customer's telecom network for de- 
ployment of the GEMF platform Sujai is profession- 
al ly interested in telecom standards and earned his 
bachelor's degree m engineering, computer science. 
duel technology in 1990 from Bangalore University in 
India Before jOtnmg HR he worked at Siemens 
Nixdorf, Inc in Munich, Germany, where he was a 
member of the team responsible for the development 
of the network element layer for TMN soluti. >, 
Siemens" SDH transmission system 
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Kenneth R, Sheers 

Ken Sheers is the technical 
marketing engineer fori he 
event correlation services 
(ECS} product developed by 
HP's Network and System 
Management Division 
(NMSD) in Melbourne, 
Australia, and is responsible 
for the supportability of the 
ECS product. Ken has been with HP for ten years, 
nj costomer support for HP-UX systems, and 





networt and systems management consorting nased 
upon the HP OpenView family, including twrc years 
consulting m she Telecom Expert Center before join- 
ing NSMD. Before commc, to HP. he spent te r 

L j m compotf 
insmjmentat i > of noise and vibration 

meas trol. 

Depar e se supporting a laser" P r 

• 
electrical engineering from Footscray Institute of 

Melbourne, Aostraita, where he was 
bom Ken is married and enjoys sbing, bush 
rock climbing, carpentry, and electronics 
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Jacqueline A, Bray 

- design engineer 
at HFs Network and System 
Management Division since 
1995, Jackie Bray is cur- 
rently the technical lead on 
the GDMO Modeling Tool- 
set Before joining HP she 
worked as a softwar- 
neer at Convex Computer 
and as a senior software engineer at Boeing Com- 
mercial Avionics, Her software development experi- 
ence includes statistical process control and demand 
flow technology for manufacturing and interference 
analysis for microwave communications, She has 
also worked on Oracle database design and adm n;s 
tration, client/server development, and system and 
network administration, Jackie received a BS degree 
in mathematical sciences with a major in computer 
science from the University of Texas in 1966 A native 
of Dubuque, Iowa, she is married and has two chil- 
dren, a daughter and a son, In her free rJ 
juys traveling, especially internationally and has been 
to over twenty countries to date, She also enjoys 
photography and outdoor activities such as water 
ski tng and downhill ■ 

52 Ma nag ei /Agent Applications 

Lisa A, Speaker 

Lisa Speaker is an ISV (inde- 
pendent software vendor) 
program manager at HP's 
Storage Systems Division in 
Greeley. Colorado. She is 
currently responsible for the 
market development and ISV 
partner programs for the HP 
SureStore Optcal jukebox 
products, Recently sfie was product marketing man- 
ager for the HP OpenView Managed Object Toolkit, 
mcludmg the development of customer training pro- 
grams. Lisa joined HP's Professional Services Organi- 
zation hi the Novi. Michigan Customer Education 
Center in 1988 She trained customers on HP-UX 
networking, and several programming languages and 
conducted open systems training on the HP 9D0O 
She also developed Introductory training courses on 
me HP-UX operating system and X -Window a/Motif 




Sne transfened to HPs Network and System Man- 
agement Division wnere she foe. : atfQn 
development and integration of HP Ope 

;HFsSNrW -work Node 

Manage? and OpenView Distributed Management 

as spoken at HP OpenView and 
Develop _^Viewapp 

/ew develops? to: 

. :ies and th-f 
, Bom in Dearborn, Michigan, she 
a BS degree in engmeenng arts in 1^3 from 
Michigan State University She a dn MBA 

in 1353 from the University of Michigan In her free 
trme, she enjoys swimming, volleyball and reading - 
She plays golf competitive I v and currently holds the 
Fort Collms women's city golf Tide 
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Alasdair D. Cox 

A senior member of the 
technical staff at HP's Bristol 
Laboratories. Alasdair Cox is 
responsible for researching 
the management of telecom 
networks and services 
Since joining HP in 1930 ■ 
has worked on knowledge 
^ base management systems 
and federated databases, and was part of the team 
that produced two TMN demonstrations for Telecom 
'35 Barn in Worthing, Sussex in the United Kingdom, 
Alasdair received a BS degree with honors in compu- 
tation from the University of Manchester institute of 
Science and Technology in 1988 His hobbies include 
photography, particularly landscape photography, 

70 Business Process Flow Management 

Ming-Chien Shan 

A project manager at HP 
Laboratories, Ming -Chi en 
Shan is responsible for re- 
search projects for h 
process management, tele- 
com network management 
electronic medical record 

VI terns, and Internet ser- 

^ vices. He joined HP in 1985 
anrl worked on an object-oriented DBMS, contnbui- 
ing to the HP QpenQDB product, and worked on a 
heterogeneous DBMS, contributing to the HP Ddapter 
product, Before coming to HP he worked at IBM for 
eight years on 002 development Ming* Co ten is 
named as the inventor in five software patents and 
has authored over forty conference and journal ar- 
ticles. He earned a PhD degree in computer scsence 
from the University of California at Berkeley in 1980 
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James W, Davis 

Jim Davis received a BS 
degree in ma III ema tics and 

an MS degree in computer 
science, both in 19BG from 
Case Western Reserve Uni- 
versity. After graduating he 
joined HP's Data Systems 
Division. He is currcn ,•• a 
member of the technical 
staff at HP LabaratOFJes and is responsible for re- 
search on business process management, telecom- 
munications network management, and Internet ser- 
vices. Recently he worked on HP OpenPM 
architecture design including the Engine and infra- 
structure Previously he worked on a heterogeneous 
DBMS, the HP OpenODB/Qdapter object-oriented 
DBMS, and another object-oriented DBMS, He also 
contributed to the XPfM lightweight network pro local 
and the compiler family for HP 900D Series 500 com- 
puters, Professionally interested in database systems, 
encryption and security, workflow systems, and pro- 
gramming languages, tie has authored over twenty 
conference and journal publications on these sub- 
jects. Before joining HP he did computer consulting 
for such companies as Occidental Petroleum and 
Ftak, Jim was born in Niagara Falls, Mew York. He is 
married and is a member of the Sunnyvale Neighbor- 
hood Actively Prepared program He and his wife, 
Sue, are active participants in modern western 
square danctng 

Weimin Du 

Weimm Do joined HP Labo- 
ratories in 1991 after earning 
a PhD degree in computer 
science from Purdue Univer- 
sity in 1991. Since coming to 
HP, he has contributed to a 

a . multidatabase research 

^^k H^ L prototype and conducted 

^™ ^^^^- research and development 
or; query processing and optimization. He also 
worked on the HP OpenPM engine design and imple- 
mentation and conducted research on compensation 
and reliability. Professionally interested in databases, 
workflows, and telecommunications, he has authored 
over twenty conference and journal publications on 
compilers, software engineering, and database and 
workflow systems Weimrn is married and has two 
children. 

Qiming Chen 

Qiming Chen received a PtiD 
degree in computer science 
m 1988 from TsingHua 
University m China.. He 
became a professor at the 
University and later moved 
to the University of California 
at Los Angeles as a research 
scientist. He joined HP Labo- 
ratories in 1992. Since then he has conducted research 
in such areas as multidatabase integration, multi- 
layer ■AC'kflow system architecture, and commit con- 
trol and failure recovery of nested transactions and 
business processes. Currently he rs working on HP's 
OpenPM project. Previously he contributed to other 





HP workflow prototypes and systems- He was ap- 
pointed to the editorial committees for several inter- 
national journals and book series, and to the program 
committees for a number of international conferences. 
Qiming has authored over fifty technical publications 
in journals, boob, and international conferences on 
databases, knowledge bases, logic programming, and 
software engineering. 
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Paul A. Stoecker 

Born in Urbana Illinois, PauE 

Stoecker received a BSEE 
deyree in 1974 and an 
MSEE degree in 1976, both 
from the University of 
Illinois After graduating he 
joined HP's Desktop Com- 
puter Division. From 1976 to 
^^^»*- 1 985 he held a number of 
hardware and firmware design positions on various 
products including the HP 9845 and HP 9GQ0 work- 
stations, He earned an MSCS degree in 1986 from 
Stanford University Since 1986 he has focused on 
software development, including C and FORTRAN 
compilers. Recently he joined HP's Network and 
System Management Division as a software develop- 
ment engineer, and is responsible for designing tools 
to assist devefopers of telecom network management 
applications, !n his free time, Paul enjoys bicycling, 
exploring the mountains nearby, and playing piano 
and organ music. 
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Reiner Lomb 

Reiner Lomb is a product 
line marketing manager at 
HP's Network and System 
Management Division 
(NSMD'I, He moved from 
BOb ling en to Fort Collins in 
1994 to assume the lead for 
NSMD's storage manage- 
ment business, including 
business planning, marketing, and representing HP 
with industry consultants and specialists. He is also 
responsible for planning strategic alliances with 
other HP divisions, as well as external partners such 
as Oracle, Sybase, and Informix. Previously he was a 
product manager responsible for HP OmniBack and 
before that, was the product marketing engineer for 
computer systems at HP's Computer Systems Bobfin- 
gen. He is professionally interested in storage solu- 
tion rjuncepts and strategies, business planning and 
marketing, and partnership strategies. He has spoken 
at conferences such as Interex. DpenView Forum, and 
the Network Storage Conference on various system 
end storage management topics Reiner earned a 
masters degree in computer science. Before joining 
HP in 1968, he worked in Germany as a project man- 
ager at Val Mehler AG, as a customer support engi- 
neer at Sperry Univac (Mow Unisys), and as a soft- 
ware research developer at Nixdorf (now Siemens 
Nixdorf). 




Kelly A. Emo 

As a software planning man- 
ager at HP r s General Sys- 
tems Division, Kelly Emo rs. 
responsible for the division s 
network and systems man- 
agement strategy and for 
product planning of systems 
management for the HP 
9000 server product line, 
Previously, she was a press and industry analyst rela- 
tions manager for networking and HP Open View net- 
work and system management products, Before that, 
she did product marketing for networking products, 
including NFS and DCE She afso dtd telephone cus- 
tomer support for HP 30OD and HP 900D networking 
products. Kelly received a BS degree in computer 
science from California Polytechnic State University 
at San Luis Obispo In 1987 While studying at Cal 
Poly, she had two coop assignments as a FORTRAN 
developer for Versatec, inc. and as a software devel- 
oper for Measure*, Inc. After graduating, she joined 
HP's Worldwide Customer Support Operation, Later in 
her career, she returned to school and earned an 
MBA from Santa Clara University in 1 995- Kelly is 
interested in public speaking and is a charter member 
of HP's Toastmasler's Club with a ranking of Able 
Toast master She was born in Santa Monica. Califor- 
nia, and is married. Her husband also works at HP 
Marathon running is a strong interest of hers and she 
finished both the 1993 and the 1996 Boston Marathon. 

Roy M Vandoorn 

Ray Vandoorn joined HP's 
Computer Support Division 
in 19B0 He received a 6A 
degree (1978) in mathemat- 
ics with a concentration in 
computer math, and an MS 
degree (19BQ) in mathemat- 
ics, both from San Jose 
State University in California. 
Currently he is the mass storage strategy and planning 
manager in the General Systems Division. Previously 
he was the product manager for HP's Open Systems 
Inconnection 1DSIJ Services. Before that, he worked 
as an BSD software engineer on X.500 and expert 
systems. Roy was born in Edmonton, Alberta, Canada. 
He volunteers his time at the American Red Cross as 
an instructor and first aid station coordinator His 
outside interests include SCUBA diving and bowling. 
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Meryern Primmer 




• 



eel interface between lab 

■ 
technical writers for the 
fibre Channel ana mass 
storage products. She re- 
cently edited the Tachyon User s Guide. She joined 
HP In 1984 as a software engineer and worked on 
Adv a nceLi nk fn r the HP 1 5 ,. , U a PCs at the 

Personal Software Division She then transferee \? 
the Roseviife Networks Division in 1986, where she 
worked on the 0S1 Express I/O board, the token ring 
I/O board, and the SCSI-2 I/O adapter board. She also 
contributed to the devetopment of the HP 9000 K-class 
server, She studied biochemistry a I the University of 
Chicago from 1867 to 1 368 and later earned a BBA 
degree with high honors m i formation systems from 
Georgia State University in 1983. Before joining HP, 
she worked as a software engineer at Symantec Cor- 
poration and as a programmer at Cox Data Services 
She is a member of the Usability Professionals Asso- 
C EftiOfl Meryern was born in Germany and grew op in 
Chicago. Her hobbies include textile arts and interior 
design. She taught weaving at Caifanwofde Fine Ans 
Center in Atlanta for two years. She also worked on a 
20- by 40- foot woven wall hanging, commissioned by 
the National Endowment for The Arts, for the lobby 
of the Federal building in CoSumbie, South Carolina 
Currently she is working on silk painting and 
fabric dyeing techniques, and is remodeling her 
recently purchased 7Q -yea no Id house. 
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Judith A Smith 

"fento, Califer- 

BS deer ; innors 

in computer science from 
a State Urn - 

Sacramento in ^BE 1 
graduating she joined HP's 

e Networks Division. 
Shr " 3 learning 

products engineer at HP's Networked Computing Drvi- 
sion and is responsible for developing learning prod- 
ucts for future Fibre Channel VLSI chips and adapter 
beards Recently she was the simulation engineer re- 
sponsible for designing and implementing the testing 
for the Tachvon chip and another VLSI chip. Previously 
the viiiulation engineer for a fast- wide SCSI 
chip. Before that she designed, implemented, and 
tested diagnostics for FDD I and LAN adapters and 
firmware for HP r s OS1 Express card She has co- 
autbored 5 previous HP Journal article on the OSI 
Express data link layer and contributed to the Fibre 
Channef/9OD0 product manual. She is a member of 
the Society of Techmcaf Communicators and a found- 
ing member of the Sierra Foothills Chapter of the 
Society of Women Engineers. Jucy is married and 
has one son. Her husband ateo works at HP In her 
free time, she is a volunteer on the HP Roseviife 
donations committee and is an advisor to California 
State University, Sacramento, on its technical writing 
curriculum. She sings baritone with Sacramento 
Valley Chorus, a chapter of Sweet Adelines Interna- 
tional, she enjoys be: rig a mom. and she likes to read 
about a variety of topics, especially child develop hit 
and world religions. 
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An Introduction to Fibre Channel 



Fibre Channel is a flexible, scalable, high-speed data transfer interface 
that can operate over a variety of both copper wire and optical fiber at 
data rates up to 250 times faster than existing communications interfaces. 
Networking and I/O protocols, such as SCSI commands, are mapped to 
Fibre Channel constructs, encapsulated, and transported within Fibre 
Channel frames. 

by Meryem Primmer 



Fit ue ( Jhannel is a standard, efficient, ggneifc transport 
mechanism whose primary la.sk is to transport data at the 
fastest speeds currently achievable with the least possible 
delay. [I is a flexible, scalable method I'm achieving high- 
speed interconnection, communication, and data transfer 
among heterogeneous systems and peripherals, including 
workstations, mainframes, supercomputers, desktop com- 
puters, and storage devices, It handles both networking and 
peripheral I/O communication over a single channel using 
the same drivers, ports, and adapters for both types of com- 
munication. 

Fibre Channel began in the late 1980s as part of the IPJ 
(Intelligent Peripheral Interface) Enhanced Physical Project 
to increase the capabilities of I lie I PI protocol. Thai effort 
widened to investigate other inlerfnre protocols as candi- 
dates for augmentation. The first year of the project was 
spent looking for existing implementations to adopt, but 
none were found to be sufficient. The focus then changed to 
d eve lop a new implementation. Th at implementation be- 
came Fibre Channel, Fibre Channel was approved as a proj- 
ect in 1988 by ANSI X3T& 

During the first year of investigation the ANSI working group 
decided to adopt a serial rather than a parallel bus interface. 
IB Ms SB/10B encode/decode scheme was adopted, and a 
decision was made to support both copper cable and optical 
fiber. Copper can be used for low cost while optical fiber 
can be used for distance. Fibre is a generic lenu used by Ihe 
Fibre Channel standard to refer to all the supporied physical 
media types. 

The Hist draft of the Fibre Channel standard was developed 
in 19S9- The standard addresses the need for very fast trans- 
fers of large \olumes of data, while at. the same time relieving 
systems of the need to support the multitude of channels 
and networks currently in use. The Fiber Channel standard 
covers networking, storage, and data transfers, In October 
IS®4 the Fibre Channel physical and signaling interface Stan 
dard. FC-PH, was approved as ANSI standard X3.230-m<->4. 

Fibre Channel is structured as a set of hierarchical functions 
that support a number of existing protocols, such as SCSI 
(Small Computer System In lei face) and IP (Internet Proto- 
col i. but it does not have a native I/O command set. 1 1 is not 
a high-level protocol like SCSI, but does contain a low-level 
protocol for managing link operations. Fibre Channel is not 



aware of f nor is it concerned with the content of the user 
data being transported* Networking and I/O protocols, such 
as SCSI commands, are mapped to Fibre Channel constructs 
and encapsulated and transported within Fibre Channel 
frames. The main purpose of Fibre Channel is to hnve any 
number of existing protocols operate over a variety of physi- 
cal media and existing cable plan is. 

Fibre Channel is a high-speed data transfer interface that 
can operate from 2.5 to 250 times faster than existing com- 
munications interfaces. Its performance is both scalable and 
extendable and it supports multiple cosL'performance levels, 
from small eonfigu rations such as disk arrays and low-cost, 
low-performance I/O devices and small systems to high 
performance supercomputers and large distributed systems. 

Fill re Channel runs at four speeds (actual data throughput ): 
100 megabytes per second (Mbytcs/s), which translates to 
1062.5 megabaud, 50 Mbytes/s or 631.26 megabaud, 25 
Mbyles/s or 265,625 megabaud, and 12-5 Mbytes/s or 132.812 
megabaud. A single 100-Mbyte/s Fibre Channel porl ran 
replace live 20 -Mbyte/y SCSI ports, in terms of raw through- 
put. Fibre Channel provides a total nei work bandwidth of 
about one gigabit per second. 

Kibre Channel operates over a variety of both copper wire 
and optica] liber at scalable distances, as shown in Table L 
Dislaiu es are easily extendible using repeaters or switches. 

Fibre Channel provides full duplex operation with separate 
transmit and receive fibers. 

Another advantage of Fibre Channel is that it uses small 
connectors. The seiial connectors used for Fibre Channel 
are a fraction of the size of SCSI parallel connectoj's and 
have fewer pins, thereby reducing the likelihood of physical 
damage. Also, depending on the topology, many more devices 
can be interconnected on Fibre Channel I ban on existing 
channels. 

Topologies 

Fibre Channel can be implemented in three topologies to 
interconnect varying numbers of devices, called nodes in 
Fibre Channel terminology. The topologies are point-to- 
point, arbitrated loop, and crosspoint switched, ot fabric (a 
111 'iv Channel term for a network of one or more switches 
connecting multiple nodes). Nodes contain one or more 
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ports, such as an I/O adapter, through which the\ communi- 
cate over Fibre Channel. A generic node port is called an 
NJtorL The connections between ports are call- 





Table 1 






Fibre Channel Media, Data Rates. 




Distances, and Transmitters 






Data Rate 


Maximum 


Transmitter 


Media Type 


(Mbytes/s} 


Distance 


Type 


dim Ttotnax or 


LOO 


■m 




STP 


50 


60m 


ECL 




_~ 


loom 




76-ohm Video 


100 


25 m 


ECL 


{ 'a ia_\ 


50 


50 ni 


VJ L 




28 


7§ ML 


ECL 






100 m 


K< L 


75*ohm Miniature 


100 


10 ni 


ECL 


Coax 


50 


mm 


ECL 




25 


30 m 


ECL 




12.5 


(0 ii 


ECL 


105-ohmlVpe-l 


25 


5il m 


ECL 


Sueldedlwiste* 


l'J~ 


loo m 


ECL 


Pair Electrical 








1 5 2 . ."► - mi i M ultimode 


100 


300 JM 


SW Laser 


Optical Fiber 


50 


WSm 


SW Laser 




25 


1 km 


LVVLKD 




12.5 


2 km 


WIMP 


50-um Mull in ii »d*-' 


100 


500m 


SW Laser 


< optical Fiber 


50 


1 km 


SW Laser 




25 


2 km 


SW Laser 




12.5 


10 km 


LW LED 


9 inn Single-Mode 


100 


lii km 


LW U,ser 


Optical Fiber 


50 


io km 


LW Laser 




SB 


10 km 





ECL * Emttter-Ccupled Lugic, LW = Longwave, SW * Shortwave, 
LED -- Light-Emitting Diode. STP = Shielded Twisted Pair 

i*oint-io paini ( Fi,^ J \ is w din^ci channel connection in- 
tween two N_PorLs, typically between ;i processor and a 
peripheral device controller. In this topology exactly two 
devices are connected together, \<> f'abrir elements exist 
;m<l no fabric services, stub as name mapping, arc nc* -i <$&aa% 
Point-to-point is the default topology. 

Fibre ChanrteJ arbitrated loop, oi n \L, is a method for 
interconnecting from two to 12*3 devices through attachment 
pom is called L_pQfrtiB in a loop configuration, LJPorts can 
consist of I/O devices and systems of various performance 
levels. FC-AL is a low-c< >si s< tail ion because it does not re 
quire bubs and switches. FC-AL is a good choice for small to 
modi urn sized configurations and provides :iti up wan I growth 

path bv interconnecting the loop mfch a fabric through an 
FL Pori Arbitrated loop is the most common Fibre Channel 
topology 

Fig, 2 shows the Fibre < hamicl arbitrated loop topology. A 
private loop (fig. 2a) consists only of nodes, called XL Parts. 
and does nol connect with ;i fabric k public loop (Fig. 2b) 
connects ttitha fabric via an FL_Port. A disk loop uses die 
toop topology to Interconnect a number oniigh-performancc 




Server 



(a) 




RAID Subsystem 



Node 2 
Storage Array 



Link 



Fig, 1* I ;s ) Twu r I e vices connected point -n»-i -- <li n i I i) F\\ ■?■■ 
1 Nanriel point bo-poinl topology Ttochyon is RP%$gabH Fibre 
introller chip. 

disk*, for example, a RAH) (Redundant Array of Inexpensive 
Disks) device. Fig. 3 shows an office configured in a public 
arbitrated loop topology, and Fig. 4 shows a private disk 
loon 

All devices on I he arhii rated loop share the bandwidth < »l the 

loop and the mnnngemcnl ol the loop. No dedi< ated loop 

master exists, and any aode is capable of being the loop 

master Which node performs l be loop ntnsl v\ f mictions is 
negotiated when the loop is initialized. 










(a) 







lb) 



rtg. 2. P!bre Channel arbitrated loop topology (a) Private Loop 
tii) Pufo& ; 
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Fig. 3. An office configured in a public arbitrated loop topology. 

Each node has equal opportunity to communicate with an- 
other node by arbitrating for temporary ownership of the 
loop. An arbitration scheme using a fairness algorithm is used 
to establish a circuit between two NL_Ports on the loop 
before they can communicate, Only one communication, or 
loop circuit, can be active at a time. After relinquishing the 
loop, an NL_Port cannot win arbitration again until all other 
arbitrating ports have had then - turn. 

The third Fibre Channel topology is crosspoint switched, or 
fabric. Fig. 5 shows a generic fabric topology, and Fig. 6 
shows the Fibre Channel fabric topology with a single 
switching or fabric clement, 

A fabric topology is implemented as one or more switching 
elements. A fabric- appears as a single entity to attached 
nodes, called F_Porls, even though the fabric can consist of 
multiple switches. Typically, a switch has from four to 16 
F_Ports attached to it. In theory, there is no size limit to the 
number of nodes that can interconnect in a fabric, but ad- 
dressing space limits the number lo a maximum n\2 24 . The 
fabric topology is good for interconnecting large numbers of 
devices and complex configurations. 



■n_^_JB 




I Taeiiyun 



Fig* 4* A private disk loop. 

The structure and operations of the fabric are transparent 
to the F_Forts attached to it. The fabric topology is self- 
managed, with the fabric performing station management 
Functions and the routing of frames. Each port only needs lo 
manage a point-to-point coiuiection between itself and the 
fabric. 

A Layered Approach 

Fibre Channel is structured as a set of five hierarchical func- 
tional levels (see Fig. 7). The user protocol being transpon i ii I 
over die Fibre Channel — SCSI or IPI ( Intelligent Peripheral 
Interface), for example — is knowm as the upper level proto- 
col (LLP) and is outside the scope of the Fibre Channel 
layers. The lachyon Fibre Channel protocol chip described 
in the article on page 99 implements the FC-1 and FC-2 lay- 
ers, which are shaded in Fig. 7. Tachyon also implements 
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Fig, 5. fabric topology. 
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Fig. <L • ; 1 fed m r tqj h * >gy with a single switching 

dement 

>t SI assists ami IP checksummings shown as shaded boxes 
at the FC-4 Level. 

FC4: The Protocol Mappings Layer. This topmost Fibre Channel 
i-vrl J' fines I he mapping of the TLP interfaces to the lower 
Fibre Channel levels. Fibre Channel supports multiple exist- 
ing protocols, including SCSI, IP. and IPI. Each ULP sup- 
ported by Fibre Channel requires a separate FC-4 mapping 
and is specified in a separate FtM document. For example, 
the Fibre Channel protoer il fur SCSI, which Is known as 
FCP, defines a Fibre Channel mapping layer itial uses the 
services Ditto lowest three Fibre Channel layers to traiiMnir 
SCSI command, dato, and status information between a 
SCSI initiator and a SCSI target. LLPs are not tied to a par- 
ticular physical medium or interface. For example, SCSI is 
supported without requiring a SCSI bus 

FC-3: The Common Sen/ices Layer. Nodes can be computer 
systems or peripheral devices. The Ft -J level defines a set 
of sen ices I hat are common anoss multiple ports of a node. 
The FC-3 layer is still being Formulated in rbe ANSI commit- 
tee and no functions have been formalk defined. 

FC-2: The Framing Protocol Layer This level de lines die signal- 
ing protocol, including the frame and byte structure, which 
is the data transport mechanism used by ftbre Channel 

Included in I h is level is the framing protocol used lo break 

saliences iuio individual frames for transmission, flow con- 
trol, ;524>it CBC generation, and various classes of sen ii 

The H -2 layer also bundles hardware disassembly and iv- 
assembly o] sequences of data. Defined in ibis layer are n 

ten hi ni i -in command primitives, railed ordered sMs t for 

handling such functions as configuration management, error 
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recovery* frame demarcation, and signaling between two 
ends of a link. 

AJrame (Fig. 8) is the smallest indivisible unit of user daca 
that Is sent on I he Fibre Channel link. Frames can be van- 
able in length* up to a maximum of 2148 byres long. Frame 
ske depends on implementation, not hardware or software. 

frame contains a four-byte Start of frame delimit - 
2-bl >f FC-l t sting 

< >f zt i , >i ionai headers and zen 

bytes of CLP data, a four-byte ( RC. and a four-byte End of 
Frame delimiter 

a set of one or more related frames. For exam- 
ple, a large file transfer would be accomplished in a sequence 
consisting of multiple frames. 

An exchange contains one or more sequences. Il Is CI mipara- 
ble to a SCSI I/O process, and is the mechanism >r < ■< m >rdi 
natingthe exchange of information between two communi- 
cating N_I*orts in a single operation. 

In general, the sequence is the Fibre Channel error recovery 
boundary. That is. selective retransmission of frames for 
error recovery is not supported in the Fibre Channel physi- 
cal and signaling interface, R" PH. If an error is detected in 
a transmitted frame and the error policy remit res error 
recovery, the sequence to which the frame belongs may 
be retransmitted, 

Fibre Channel provides three classes of service, which are 
managed by the FC-2 layer "lass 1 dedicated connection 
service provides a dedicated or circuit-switched connection 
between two N_Poiis. Hie connection musi be established 
before communication can begin and must be lorn down 
when communication is completed. Class I guarantees de- 
livery of frames in the order in which they were transmitted 
l onfirmation of delivery also is provided. Class 2 multiplex 
service provides a connectionless, frame-switched link. De- 
livery is guaranteed, but nol necessarily in order il multiple 
routes cxisl through the Fabric, Class '1 also provides ac- 
knowledgement of receipt ( l;iss 3 datagram service is a 
connectipriless sen t£e similai to class % bud wdthbul con- 

linnation of receipt. Neither delivery nor receipt order is 
guaranteed in class i 

FC-1: The Encode/Decode Layer. "I i defines the trans- 

nussion protocol, including the 8B/I OB encode decode 
scheme, byte synchronization, and character-level error 
control. 8B/10B is a tfc-balanced encode/decode scheme that 
provides good Transition density for easier clock recovery 
and character-level error detection. In this scheme, 8-foh 
internal bytes are encoded and transmitted on the Fibre 
Channel link as lo-bir transmission characters The trans 
nussion i lini alters are converted back inlo.S-bh bytes at the 
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receiver, I sin^ l(i bits for each character provides 1024 > 
sible encoded values rathea than only i Jk- 2§6 values thai b& 
possible for 8di it characters. Not all of the 1024 possible 
values are used. To maintain a do balance on the link, only 
those that contain Four zeros and six ones, six zeros and 
four ones, or five zeros and five ones are used. Some of the 
extra 10 hil rliararter> ;nv used for low-level link eonfn >1. 
One special (character railed a cmttma is used for byte 
synchronization. 

FC-0:The Physical Layer. FC-0\ the luwes! ol "Hie five levels, 
defines the physical characteristics of the media, including 
cables, connectors, drivers ('ECL, LEDs, shortwave lasers 
longwave lasers, etc.), transmitters, transmission rates, n 
ceivers, and optical and electrical parameters for a variety 
of data rales and physical media. Reference 1 describes HP 
products that implement the FC-0 layer, 

Collectively, the three lowest layers const ilule the Fibre 
Channel physical and signaling interface, FC I ML Ft -PI I is 
a channel/network hybrid. It supports channel interfaces 
for peripherals — for example, SCSI 1P1 T kind 1IIPFI { llitfh- 
Performancc Parallel Interface)— as well as network proto- 
cols such as TCP/IP. F( -Pit is similar enough lo a network 



to gain connectivity, distance, and serial interfaces, while 
being enough like an i/< > channel to retam simplicity, reli- 
ability, and hardware functionality. 

Reference 

L J.S, Chang, e4 aJ,"A L&G&6 i.ur/si-'iiuvi hanneJ Chipsei with 
Laser I /river, ' HewlettrP&ck&rd Journal V5 <l 17, no. I, Febi uarj 
L996, pp. 60-67. 
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Tachyon: A Gigabit Fibre Channel 
Protocol Chip 

The Tachyon chip implements the FOI and Ff>2 layers of the five-layer 
Fibre Channel standard. The chip enables a seamless interface to the 
. sieal FOQ layer and tow-cost Fibre Channel attachments for hosts, 
systems, and peripherals on both industry-standard and proprietary buses 
through the Tachyon system interface. It allows sustained gigabit data 
throughput at distance options from ten meters on copper to ten 
kilometers over single-mode optical fiber 

by Judith A* Smith and Mervcin Primmer 



Relentlessly increasing demands of computer systems con- 
tinue to stress existing eonununlcation architectures in their 
Limits. Even as processor speeds continue to improve dramat- 
ically, they arc haicK keeping up with increasing numbers of 
concurrently running applications and ('PI -intensive appli- 
cations, such as multimedia, with higher data throughpul 
reuuiremenis. Additionally as the jnnnherof intereonneets 
between systems and I/O devices continues ro iacfl 
I/O channels become bottlenecks to system performance. 
A channel such as SCSI (Small Computer Systems Enter- 
face), which operates ad a maximum rhroughpui of 20 mega- 
bytes per second in lasi ;i[id wide mode, simply cannot keep 
pace wiih ever-increasing processor speeds and data rate 
requirements- 

toother challenge of contemporary computer systems is ihc 
trend to more widely distributed systems, which require 
greater interface distances. Currenl parallel bus intercom 
nects between systems and their I < * de* ices cannol operate 
M\< i the distances needed For tr^ie distributed systems, such 
as LANs spanning campus areas and hij*h availability appli- 
cations requiring remote mirrored disks for disaster recov- 
ery. SCSI, for example, is limited to a distance of six meters 
single-ended (single wire per signal > and 25 meters differen- 
tial (two wires per signal}, 

Current peripheral miercnnnen prom, nls are hunted in the 
number of devices they can iulcrcnnneel. For example, par 
aJlel SCSI can conneri eight devices and lb hit wide SCSI 
Can conned tfidgyice& In addition, peripheral mnneiiors 
arc becoming too large to tit ini<> the shrinking footprints 
systems ami peripherals. I Ither SGS3 limitations include hall 
duple* Operation imly, lack of a switching capability, inabil- 
ity to interconned individual buses, and die need forcua 
lomized drivers and adapters for various types of attach d 
devices. 

i omputa mm mi real estate also is becoiuing scarce and cx- 
pensive, hieled by increasing numbers of racked computer, 
insnfficieni room to conned desired numbers of peripheral 
devices, and more complex cabling, At the same nine, data 
storage requirements are skyrocketing as backups of lera- 
ofdata are becoming coinmonplaceH An additional 



problem is thai ever -increasing amounts of data must be 
backed up over too-slow LANs, making timely, low-cost 
backups ever more difficult to accomplish. 

For all these reasons, todays parallel bus architectures are 
reaching their limits. Fibre { Jhannel i >ro\ ides solutions to 
many of these limitations. Fibre ( naniiel is a forward-thin k- 
ing solution to future mass storage and networking require 
merit*, Ihe article on page -M presents a technical descrip 
feion of Fibre Channel 

III* and Fibre Channel 

Searching for a higher-performance serial interface, HP in 
vestigated a number of technologies, HI* chose Fibre * Chan- 
nel overother serial technologies because it supports sus- 
tained gigabit data transfer rates [the fastest throughput of 
any existing interface), h alio ws networking and mass stor 
age on the same link, and it is an open industry standard. 

Although Fibre Channel faces the challenges of lack of mar- 
ket awareness and industry coordination and a perception 
that ii can be expensive, it is a stronger contender than al- 
ternative serial technologies for a mimhn ofimportanl rea 
sons. Ii is an open industry standard and an approved ANSI 
standard, ii has vendor supporl from switch, hub, and disk 
drive suppliers, ii is extensible, offering three topologies and 
lour data transfer rates, and it supports both networking and 
mass storage, 

Fibre Channel's increased bandwidth pro* ides distance flcx- 
ibility, increased addressability, and simplified cabling. Fibre 
Channel has versatility, room for growth, and qualified ven- 
dor support Mass storage suppliers are using Rbre < hannel 
to Interconnect subsystems and systems and to control em- 
bedded disk drives- Some rnidrange system (server) supph- 
i are using Fibre Channel as a clustering interconned and 
for specialized networking. Fibre Channel supporters and 
developers include HP, Sun Microsystems. SCh and IBM I'or 

workstations, IIP, Sun, Unisys, and ( Compaq in the server 
market, ill'. Seagate, Quantum, and Western Digital for disk 
dj ives, and I rata I reneral's I lariiwu Business Unit, DEC, 
Symbios, Fujitsu, and BMC for disk arrays, in addition to 
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Fig, 1. HP ih ^duiolDgies. 

over 100 other vendors [source: The Fibre Channel Associa- 
tion). 

Fibre Channel's main virtue is ihai it winks as a networking 
interface as well as a channel interlace. Fibre Channel is 
one of ihree complementary networking technologies that 
HP sees as the next step upwards in network performance 
(see Fig. 1). The Other two technologies are ATM (Asynchro- 
nous Transfer Mode), and IEEE 802.12. which is also known 
as lOOVG-AnyLAN or 100BT. 1 Each technology has a set of 
strengths and is best si tiled to a particular networking nic In . 
Combined, these technologies support all aspects of net- 
working. 

Both Fibre < hanuel and ATM are switched systems. They 
can share the same Cable plant and encoding scheme and 
can work together in a nelwork (Fig, 2) However, Fibre 
Channel and ATM standards are evolving independently to 
resolve different customer needs and objectives. ATM. 
which is telecommunications-based, is intended for applica- 
tions that are characterized by "bursty" types of communica- 
tions, thus lending itself to WAN applications. lOOVG-Any- 
LAN or lOOBT provides low-cost, high-performance client 
attachments. Fibre Channel is data eomniunicat ions-based 



and particularly well-adapted Cor networked and embedded 
mass storage, clustering, and specialized networking appli 
cations requiring sustained data flow rates. 

In addition, Fibre Channel resolves the "slots and watts" 
problem that current symmetric- multiprocessing systems 
have. For example, in 19!>">. three FDDI ports and six fast 
and wide SCSI ports were required to use fully the I/O capa- 
bilities of a symmetric multiprocessing IIP server, Fibre 
Channel could support these I/O services with just three 
slots. 

HP's vision of Fibre Channel is thai ii is at the core of the 

virtual data center containing diverse elements including: 

Fit »re Channel switches connecting mainframes and super- 

computers 
i Network-attached disk arrays and storage archives 

ATM, FDDI, and Ethernet routers 
1 Imaging workstations 

Fibre Channel arbitrated loop disks and disk aiTays 

High-performance mass storage peripherals 

Low-cost clients 

Clustered systems 

Video, technical, and commercial servers. 

Interoperability and the establishment, of a critical mass o\' 
Fill re Channel products are the keys to the success of Fibre 
Channel. IIP is committed to Fibre Channel and is working 
with partners and standards bodies to ensure interoperabil- 
ity. IIP is an active participant in the ANSI I^ibre Channel 
Working Group, the Fibre Channel Association (FCA). and 
(he Fibre Channel Systems Initiative, which hits been talc 
grated into the FCA. In 1994 HP purchased Cansiar. a Fibre 
Channel switch company, which is now HP's Canadian Net- 
works Operation, HP has developed Fibre Channel disk 
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drives, gigabit link modules and transceivers, 2 system inter- 
faces, and the Taehyon protocol controller chip, which is the 
subject of i his article. HP is using Fibre Channels versatility 
and speed for high-availability mass storage solutions and 
clustered system b 

Taehyon Chip 

The system interconnect laboratory of the HP Networked 
Computing Division became interested in Here Channel in 
1993 as a method of entering the high -rial intercon- 

nect marker because Fibre Channel was the first technology 
ihat could be used for both networking and mass storage. 
HP decided to develop the Taehyon chip in mid -1993 after 
investigating which Fibre Channel controller chip to use in a 
Fibre Channel hos! adapter card under development for the 
HP 9000 Series 800 K-class server. 5 The investigation deter- 
mined that no available chipset would meet the functional 
or performance requirements, so l he decision was made to 
develop a controller internally 

Tlie Taehyon chip (Fig. 3) implements the FC-1 and PC-2 
layers of the five-layer Fibre Channel standard I see article, 
page 94). Taehyon s host attach enables low eust gigabit 
host adapters on industry-standard hoses including PCI, 
PMC, S-Bus, VME. EISA. Turbo Channel, and MCA. It is easi- 
ly adaptable both to industry-standard and proprietary buses 
through the Taehyon system interface (a generic interface) 
and provides a seamless interface to GLM-compliant mod- 
ules and components. GLM (gigabaud Link module) is a pro- 
file defined by the FCSI (Fibre Channel Systems Initiative) 
and adopted by the FCA (Fibre Channel Association), li is a 
subset of the Fibre Channel FC-0 layer/* 

Taehyon provides gigabit data throughput at distance op- 
i n ins from 10 meters <m copper to 10 kilometers over single- 
mode Optical fiber, Taehyon host adapters save system slms, 
minimizing eosl and tabling infrastructure. 



Taehyon achieves high performance and efficiency because 
many of its lower-level functions are implement ed in hard- 
ware, eliminating the need for a separate nucroproi 
chip. Functions such as n abound user data 

from sequences into I Vainer, reassembly of inbound data 
flow control, data encoding and decoding, and simple low- 
level error detection at The transmission character level are 
all built into hardware. One set of hardware supports all 
upper-level protocols. Errors and exceptions are offloaded 
to host-based upper-level software to man 

Taehyon High-Level Design Goals 

The Taehyon designers made several high-level design dei i- 
sions early in the project The primary design goal w; 
deliver suslained. full-speed gigabit performance while im- 
posing the minimum impact on host software overhead, To 
accomplish this, Taehyon supports all Fibre Channel classes 
of service (see article, page 94 h automatically acknowl- 
edges in hound frames for class 1 and class li handles 
NL_Porl and N_Port initialization entirely in hardware, man- 
ages concurrent inbound and outbound sequences, and uses 
a messaging queue to notify the host of all completion infor- 
mation. To offload networking tasks hum hosts, Taehyon is 
designed to assist networking protocols by supporting IP 
checksums and two different modes for splitting network 
headers and data. 

if, second major design goal was that Taehyon should sup- 
port SCSI encapsulation over Fibre ChanneJ \ known as 
f T CP). From the beginning of the project, Taehyon designers 
ereated SCSI hardware assists to support SCSI initiator 
transactions. These hardware assists included special queu- 
ing and caching. Early in the design, Taehyon only sup- 
ported S( SI initiator fuiuNuiiaiity wiih its Si "SI hardware 
assists. 11 became evident from customer feedback, hov\ 
ever, that Taehyon rmisi support SCSI target funclionalii.v as 
well, so SCSI target functionality was added to Taehyon 
srsi hardware assists. 




Fig, a, HI' Ti'hvin Fibre * Channel i patroller chip, 



Taehyon Feature Set 

To take advantage of Fibre Channel's high performance, 
Taehyon: ; ' 

lVo\ tdes a single-chip Fibre Channel solution. 
Manages sequence segmentation and reassembly in hard 
ware. 

Automatically generates acknowledgement ( ACK) Frames for 
inbound data frames. 

Automatically intercepts and processes ACK frames of out- 
bound data frames. 

Processes inbound and outbound data simultaneously with 
a full duplex architecture. 

Allows chip transaction accesses it) he kepi at a minimum 
bv means of host-shared data structures. 

To provide the most flexibility IV>r customer application** 
Taehyon: 

Supports link speeds of LQ63j 531, and 366 Mbaml. 
Supports Fibre Channel class i, 2, and 3 sen ices. 
Supports Fibre Channel arbitrated loop U^ -AD. point n> 
point, and fabric [crosspoim switched) topologies. 
Provides ;i clueless i ■< in ilci i mti to industry-standard physi- 
cal link modules such as gigabaud link modules. 
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• Supports up to 2K-byte frame payload size for all Fibre 
Channel classes of service, 

• Supports broadcast transmission and reception of FC-AL 
frames. 

• Allows time-critical messages to bypass the normal traffic 
waiting for various resources via a low-latency, high-priority 
outbound path through the chip. 

• Provides a generic 32- bit mid plane interface — the Tachyon 
system inlerfarc. 

To provide support for customer networking applications, 
Tachyon: 
i Manages the protocol for sending and receiving network 
Sequences owr Fibre Channel 

• Provides complete support of networking connections. 

• Computes exact checksums for outbound IP packets and 

i ust j I m them in the data stream, thereby offloading the host 
of a verv compute intensive Task. 

• Computes an approximate checksum for inbound IP pack- 
ets thai partially offloads ihe checksum task from the host 

• Contains hardware header/data splitting for inbound SNAP/ 
[P sequence? 

To provide support: for customer mass storage applications, 
Tachyon: 

• Supports up to 16,384 concurrent SCSI L/< ) transactions, 

< m be programmed to function as either an initiator or a 
target. 

• Assists the protocol for peripheral I/O transactions via SCSI 
encapsulation over Fibre Channel (FIT). 

To reduce host software support overhead, Tachyon: 

• Allows chip transaction accesses to be kept at a minimum 
by means of host-shared memory data structures. 

o Manages interrupts to one or zero per sequence. 

• Performs FC AL initialization wilh minima] hosi interven- 
tion, 

To provide standards compliance, Tachyon: 

• Complies with Fibre Channel System Initiative (FCSI) pro- 
Hies. 

• Complies with industry-standard MJB-Il network manage- 
ment. 

To ensure reliability, Tachyon: 

• Supports parity protection on Lis internal data path 

• Has an est i mated M TB F o f 1 . tf j n i 1 1 i on lion rs. 

Fabrication 

tachyon is fabricated by LSI Logic Corporation using a 
0,5-um 3.3V CMOS process, LCB500K. The chip dissipates 
just under 4 watts and is contained in a 208-pin MQIIAD 
package with no heal sink. 

Tachyon Functional Overview 

The host interface of the Tachyon chip is a set of registers 
used for initialization, configuration, and control and a set of 
data structures used for sending and receiving data and lor 
event notification This interface is very flexible and allows 
the customer to design an interface to Tachyon that best 
meets the capability, performance, and other requirement 
of a specific application. 



Transmitting a Fibre Channel Sequence 

To transmit an outbound sequence (see Fig. 4), the host 
builds several data structures and sets up the data to be 
nansniitred. A data structure called the fntfbfHUf.fi deseHptOT 
block is buill first The outbound descriptor block provides 
much of the information Tachyon needs to send a sequence, 
The outbound descriptor block points to a data structure 
called the futonled descriptor block, which points to data 
buffers containing the data iter the sequence. The host then 
creates the Tachyon header structure, which contains im- 
pnrianl Fibre Channel-specific information such as which 
Fibre Channel * hiss Of service to use during sequence trans- 
mission. The host sets up the outbound descriptor block to 
point to I he Tachyon header structure. The host then adds 
the outbound descriptor block to the outbound command 
queue. 

Wh€I1 Tachyon sees the new entry in the outbound command 
queue, it gels the outbound descriptor Mock frum host 
memory via DMA. As Tachyon reads the Tachyon header 
structure to send the first frame of the sequence, it copies 
the header structure to internal register's for use in generating 
Fibre Channel headers for subsequent frames* 

II ' 1 his Ls class 1 service, after sending Ihe first frame, Tachyon 
waits until it receives the ACK for the first frame of the se- 
quence before continuing, Tachyon then inserts an identifier 
val ue , called t he i wp Q uder i -. i i %&n g t \ i cfet! / / / »r ( R X _ I D .) , 
which is returned in Ihe ACK, into the Fibre Channel header 
on all subsequent frames Of this sequence. Tachyon contin- 
ues to transfer data from the host via DMA in frame-sized 
blocks and sends the frames with headers automatically 
generated from the previously stored header 

Tachyon keeps track of the frame coimt for the sequence. 
The Fibre Channel header for each frame contains an incre- 
mental count of the number of frames transmitted Tor the 
sequence along with the relative posit ion of thai frame with- 
in the sequence. As Tachyon sends the frames for the se- 
quence, it also tracks How control for the sequence using a 
Fibre Channel How control method called end-to-end credit 
(EE_Credit I EE_Credit determines the number of frames that 
Tachyon can send to the remote destination without receiv- 
ing an ACK. Each time Tachyon sends a frame, EE_Credit 
decrements. Each time Tachyon receives an ACK from (he 
destination, EE_Credit increments. If EE_Credit goes to zero, 
Tachyon stops transmitting frames and starts a watchdog 
timer called the ED_T0V timer (error deled timeout value), 
The ED..T0V timer counts down until ACKs arrive. If ACKs ar- 
rive, Tachyon resumes transmission. If the EDJfW timer ex- 
pires, Tachyon sends a completion message to the host indi- 
cating that the sequence has timed on I. 

Once Tachyon has transmitted the last frame of a sequence 
and received all of the ACKs for ihe sequence, it sends a tone 
plelhm message to the host via Thr- inbound message queue. 
This tells the host thai it can deallocate all memory associ- 
ated with this outbound descriptor block and inform any 
processes waiting on its completion. If a sequence terminates 
abnormally, Tachyon will notify the host of the error in the 
completion message. 
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Fig. 4. Transmit process ov 



Receiving a Fibre Channel Sequence 

Fig. 5 shows an overview of the receive process. To enable 
Tachyon In receive data, the hos1 first supplies Tachyon 
wil h iwo queues of inbound buffets. Two inbound queues 
are r( quired because single-frame sequence rocepiion and 
multiframe sequence reception are handled independently, 
Tachyon needs minimal resources to receive a single-frame 
sequence, but for muUiframe sequences the chip needs to 
use additional resources to manage the reassembly of 
frames- Because of This resource demand. T;t< \ iyon can 
semble only one incoming imilfifrume nei working sequence 
at a time. Tachyon supports the reception of single-frame 
sequences while reassembling a muJiinaaie sequence. I 
process allows a host to receive short sequences while 
Tarhyon is reassembling a longer incoming sequence, 

Single-Frame Sequence Reception, The hosts uses the single- 
frame sequence buffer queue lo inform Tachyon of the loca- 
tion of host-based buffers thai Tachyon should use to re- 
ceive sequences contained within a single frame. As 
Tachyon receives a single-frame sequence, it places the en- 
tire sequence, Which Includes the Tarhyon header structure 
followed hy the sequence tlala. in l he buffer defined hy the 
address from tin- single-frame sequence buffer queue, if the 
sequence is larger than one buffer size, ihe remaining data 
Of the sequence is packed into the next buffers, as required. 
hi iii I all of i he sequence is stored. Next, Tachyon sends an 
inbound_sfs_completion message to the host via the inbound 
message queue and generates an interrupt to the host 



Multiframe Sequence Reception. The host uses the multiframe 
sequence buffer queue to inform Tachyon of die location of 
host -based buffers thai Tachyon should use hi receive and 
reassemble incoming data that has been split into an arbi- 
trarily large number of frames. When Ihe first frame of a 
new sequence arrives, Tachyon copies the Tachyon header 
Structure into the beginning of the next available multiframe 
sequence buffer. Tachyon packs the data pay load of the 
Craxne into Ihe next buffer following U\e buffer with the Ta- 
I'liV'ti header structure. As each new frame arrives. Tachyon 
discards the Fibre Channel header information and sends 
Ihe data to the host. Tachyon packs this data inio each of 
ihe buffers on the multiframe sequence buffer queue, obtain- 
ing a new buffer when the current buffer is full, until Ihe 
entire sequence is stored. Once all the frames arrive and the 
sequence is reassembled in memory, Ibchyon notifies Hie 
host thai the entire sequence has been received by generat- 
ing a completion message and placing if into the inbound 
message queue. Tachyon then generates a host interrupt lo 
process Ihe entire sequence. 

Tachyon can also handle multiframe sequences that are re- 
ceived out of order. When Tachyon detects an out-of-order 
frame, Tachyon generates a completion message that indi- 
cates Ihe in-order portion of the sequence and ihe last se- 
quence buffer used. Tachyon passes the completion mes- 
sage to the inbound message queue, but does nol generate 
an interrupt umil all frames of ihe sequence are received. 
Next, Tachyon obtains the next available sequence buffer 
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and copies die Tachyon header structure of this out-of-order 
frame into it. Then, into the next sequence buffer, it copies 
the data payload of this out-of-order frame. At this point, if 
tlie frames that follow the out-of-order frame are In order, 
Tachyon discards the Taehyon header structures and packs 
the data into the host buffers. Tachyon packs this data into 
each of the buffers on the multifranie sequence buffer 
queue, obtaining a new buffer when the current buffer is 
fuJJ. until the entire sequence is stored. If another frame ar- 
rives out of order from the previous out-of-order portion, 
Tachyon generates a new completion message and the pro- 
cess is repealed. When it receives the final frame of the se- 
quence, Tachyon passes it to the host and generates a com- 
pletion message. At this time, Tachyon generates a host 
interrupt to process the entire sequence. With the informa- 
tion in each of the Tachyon header structures that Tachyon 
passed to the host for each in-order portion and the informa- 
tion in the completion messages, the host has enough infor- 
mation to reorder die out-of-order nmltirrame sequence. 

Tachyon Internal Architect ure 

Tachyons internal architecture is illustrated in Fig, tj r Each 

functional block in the architecture is described below. 

Outbound Message Channel The outbound message channel 
block manages The outbound command queue. It maintains 
the outbound command queue as a standard circular queue. 



= Inbound Message Queue 

- Si ng I e F ra me S e que nee 
Buffer Queue 

- Mm It [frame Sequence 
Buffer Queue 

= Inbound Sequence Manager 

- Outbound Sequence Manager 



Fig. 5. Receive process overview. 

The outbound message channel iiiforms the outbound se- 
quence manager block when an outbound command is wait- 
ing in host memory to be processed, When requested by the 
outbound sequence manager, the outbound message channel 
then reads one 32-byte entry from the outbound command 
queue and delivers it to the outbound sequence manager 
I ilock for processing, 

High-Priority Message Channel. The high-priority message 
channel block manages the high-priority command queue. 
The host can use the high-priority channel to send urgent 
single-frame sequences that need to bypass the dedicated 
outbound command queue. For example, the host could use 
flu' high-priority command queue to send special Fibre 
Clmnncl error recovery frames that might not otherwise be 
transmitted because of a blocked outbound command 
queue The high-priority message channel maintains the 
high-priority command queue as a standard circular queue. 
The high-priori I v message channel informs the outbound 
sequence manager block when a high-priority outbound 
command is waiting in host memory to be processed When 
requested by the outbound sequence manager, the higli 
priority message channel reads one entry from the hi^h- 
priority command queue and delivers it to die outbound 
sequence manager block for processing. 
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IMQ = Inbound Message Queue 

SFSBQ = Single-Frame Sequence Buffer Queue 

MFSBQ = Multiframe Sequence Buffer Queue 

SEST - SCSI Exchange Slate Table 

DCQ - Outbound Command Queue 

HPCQ = High-Priority Command Queue 



SCSI ■ SmaEI Computer System Interface 

ISM = Inbound Sequence Manager 

OSM = Outbound Sequence Manager 

OS = Ordered Set 

CRC a Cyclic Redundancy Check 



Fig. fi. TnHiynn Internal archft< i 
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Outbound Block Mover. Tin- outbound [dock mover block's 
function is in transfer outbound data from host memory io 
Hum nit hound sequence manager via DMA. It lakes as m$m\ 
anadrtr ess/I ength pair from the om hound sequence manager 
block, initiates the Taehyon system interface bus owner- 
ships. Mud performs the most efficient number and size of 
transactions on t lie Taehyon system interface bus Io pull in 
the data requested. 

Outbound Sequence Manager. The outbound sequence manage 
block is responsible for managing all outbound sciences, 
The outbound message channel, the high-priority message 
channel, and the SCSI exchange manager notify the out- 
bt mad sequence manager block when they have data to 
send. The outbound sequence manager must determine 
which channel has priority, IJigh-prinriiv sequences have 
first priority, but die ouiboiurd sequence manager deter- 
mines priority between networking and SCSI transactions 
using a fairness algorithm. Once priorily is determined, ihe 
outbound sequence manager programs ihe out hound mes 
sage channel to retrieve a data sequence from hosi memory 
and segment it into individual frames for transmission. The 
f unbound sequence manager transmits the sequence, per- 
forms a TCPor UDP-type checksum on die sequence, veri- 
fies that each frame is acknowledged by Ihe receiving node, 
handles errors if required, and sends a completion message 
to the host through the inbound message channel. 

Outbound Frame FIFO. The outbound frame FIF< > buffers data 
before transmission to prevent undermm Tins FIFO is sized 
Ui hold one maximum-size frame. As Taehyon sends the cur- 
rent frame onto the link, the outbound frame FIFO is simul- 
taneously filled with the nexl frame, maximizing outbound 
p erf o r n tance an d re< 1 1 ici rig late ncy. 

ACK FIFO, The ACK FIFO holds Fibre Channel efctsg I and class 
2 ACKs until they can be sent out by the frame manager. 

Frame Manager. The frame manager is Taehyon "s interface to 
lire physical link module. The frame manager implements 
the \_Port stale machine described in the FC-PH specifica- 
tion and the loop state machine described in the FO-AL 
specification. The frame manager can be 1 configured to sup- 
port link speeds of 1068., 531, and 2tMi megabits per second. 
It also implements initialization in hardware for both 
NL_Forts and N_Ports. 

The frame manager implements portions of the FC-1 and 
FC-2 specifications. 11 is responsible for Ihe FC-1 functions 
of transmitting and receiving Fibre Channel frames and 
primitives. It Calculates and verifies the CRC for frame data, 
checks parity of the transmit data, and generates parity for 
the receive data. It generates primitives, encodes ana 1 re- 
ceives Fibre Channel frames and primitives, decodes 10-hii 
or 20-bit physical link module data, and implements the run- 
ning disparity algorithm in FC-L The frame manager can be 
configured to generate interrupts to ihe host when certain 
link configuration changes occur- to which the host imisi 
respond. The interrupt process occurs as part of N h art 
initialization and loop initialization and any lime the link has 
b&esfr disrupted. 

The ordered set and CRC generator encapsulates da la into 
FC-1 frames, generates a ^2-hii cyclic redundancy check 
(CRC), writes it into the frame, and passes the encapsulated 



data to the L6&20B encodes The 16B/20B encoder converts 
outbound 16-bit-wide data into two 8-bit pieces, each of 
which is encoded Into a Ju-bn transmission character using 

ihe 8B/10B encoding algorithm. 

The 20B/10B multiplexer is responsible for selecting ih. 
proper width, either If) bits or 20 bits, of the dala path for 
ihe specific type of physical link module being used The 
data width and speed me specified by the parallel li> Geld of 
the physical link module interlace 

The 1 OB/20 B demultiplexer is responsible lor receiving in- 
coming encoded daia. either 10 bits wide or 20 bits wide, 

from Ihe physical link module and packing it Into 20 bits Ioj 
decoding The data width and Speed are specified by the 
parallel ID field of the physical link module interface. 

The 20B/lbB decoder is responsible for converting ^0-bil- 
wide data received from the 10B/2HB demultiplexer into i\\o 
S-hit data bytes. 

Tire elastic Store and smoothing block is responsible for 
retiming received data from the receive clock to the trans- 
mit clock. The elastic store provides a flexible data FIFt » 
buffer between the receive clock and transmit clock do- 
mains. Receiver overrun and un demur can be avoided by 
deleting mid inserting duplicate primitives from the elastic 
Store as needed to compensate for differences in receive 
dock and transmit clock frequencies (within specifications). 

The ordered sei processui and f'RC checker block isn • 
sponsible for detecting incoming fiame boundaries, m \i\'\ 
Lngthe cyclic redundancy check, passing (he data to the 
inbound FIFO, and decoding and recognizing primitives. 

Inbound Data FIFO. The inbound daia F1F( ) buffers frame data 
while the frame manager' verifies Ihe CRC. It also serves as 
high-uvaiiabilily temporary storage to facilitate the Fibre 
Channel, flow control meehanisms. This FIFO is sized to 
hold a maximum of four 2K-byte frames (including headers). 

Inbound Sequence Manager. The inbound sequence manager 
is responsible fur receiving and parsing all link control and 
link data frames, h interacts with the SCSI buffer manager 
block to process SCSI frames. The inbound sequence man- 
ager block is also responsible for coordinating r I it • actions 
laken when a link reset is received from ihe frame manager 
block and for passing mil bound completions to the inbound 
data manager block. The inbound sequence manager also 
manages class 1 Fibre Channel connections. 

Inbound Data Manager. The inbound data manager routes 
incoming frames to 1 heir appropriate buffers in host mem- 
ory, transferring Si SI FCP_XFER_RDY frames feo ttie SCSI ex- 
Change manager, sending completion messages to the in- 
bound message queue, and sending interrupts Io Ihe 
interrupt controller inside the inbound message channel. 

Inbound Block Mover. The inbound block mover is responsi- 
ble im DM A rompers of inbound data into buffers specified 
by file mutril'ramo sequence buffer queue, the single-frame 
sequence butler queue, the Inbound message queue, or the 
SCSI buffer manager. The inbound block mover accepts an 
address from the inbound daia manager, then accepts the 
subsequent daia stream and places (lie daia into ihe location 
specified by the address. The inbound block mover also 
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: MCer index updates and intern ipt requests from 
the inbound message channel and works with the arbiter to 
put the interrupt onto the Ta Steifi interface bus. 

Inbound Message Channel The inbound message 
maintains the inbound message qpaeue Tliis includes supply- 
ing the inbound & gear with the address of the next 
available e wry in the inbound n teoe and g 
on message when the number of avail 
? the inbound mette is down to tv 

The inbound message channel also generates interrupts for 
completion m* ; handles mess 

and interrupt ordering. The completion message must be in 
the hosi memory befon mipt. Trie inbound mess 

channel also handles interrupt avoidance, which minimi 
the number of interrupts (strobes on the INT pin on ihe 
Tachyon system interface bus) asserted to ihi* liost for each 
group of completions sent to the host. 

Single-Frame Sequence Buffer Channel. The inbound single 
frami' sequence binder channel manages the saagle-frarae 
sequence buffer queue. It supplies addresses i tf empty 
single-frame sequence buffers to the inbound data man 
and generates a completion message when the supply of 
smgie-frame sequence buffers runs u t w. 

Multiframe Sequence Buffer Channel. The inbound mulliJ'ranie 
sequence buffer channel manages the muliiframe sequence 
buffer queue, it supplies addresses of empty multiframe 
sequence huffers to the inbound data manager and genei 

a completion message when the supply or multiframe 
sequence buffers tuns low. 

SCSI Buffer Manager. The SCSI buffer manager is responsible 
for supplying ihe inbound data manager with addresses of 
buffers to be used for inbound sesi data frames, The SCSI 
buffer manager maintains a cache of lb unique st si descrip- 
tor blocks. Bach block contains eighi SCSI buffer addre 
Depending upon the direction of the exchange, the origina- 
tor exchange Identifier (OXJD) or the responder exchange 
uientiller (RXJD) of the current frame is provided by Ihe 
inbound data managei block and is used to point to tiie cor- 
reel entry in Ihe St SI exchange slate table, 

SCSI Exchange Manager In conjunction with the 9 SI ex- 
change state table data strm ture, lh< SCSI exchange manag 
er provides Tachyon with the hardware assists for S< SI f ■« \ 
transactions. It converts SCSI exchange state table entries 
h> outbound descriptor block formal for the outbound se 
qvtence manager block's use The SCSI exchange manager 
accepts SCSI Outbound FCP_XFER_RDY frames from the in 
bound data manager block- It then uses the OXJD or RXJD 

given in the frame as an offset into the stale table, leads Ihe 
entry, and builds the outbound descriptor block 

Register Block, lln- register block consists of control, config- 
uration, and Status registers These registers an* used lor 
initialization, configuration, control, error reporting, at d 
maintenance of ihe queues used to transfer data between 
Tachyon and ihe host Each register is 32 bits wide and rttaj 
be readable or both readable and writable by the hosi de- 
pending upon iis function- 
SCSI Read/Write Channel, The si s\ readAvrite channel man- 
ages requests from the SCSI exchange manager and inter- 
faces to the Tach>nn system interface arbiter block. 



Tachyon SCSI Hardware Assists 

Tachyon supports S« Sim transactions (exchanges) by two 
methods. The first met I ■ ■ 1 transaction man- 

agement. In this method, the host transmits and receives live 
various seqw -i^ral transmit and receive 

pre using th- n management 

method, Tachyon reassembles only one S( "SI m 
inuliiframe sequence at a rime. The second method uses 
Tael ->I hardw;: With This nieThmh Tachyon 

-Ls the host transaction management through th 
a shared host data structure railed the s< M exchange State 
table. 

Hv using Tachyons SCSI hardware assists, the host can con- 
currently reassemble up lo l*i.;*S4 S< S quences. 
Tachyon maintains an on-chip cache for up to lb concurrent 
in boujid transactions lachyoc usesafcosl recentty 
caching algorithm to aflon Bie most active exchanges to 

Complete their transfers wilh the minimum latency. 

The protocol U i S SI encapsulation by Fibre Channel is 
km iwn as FCP. Fig. 7 shows an I >ver\ u\\ n\ the FCP read 
exchange arid Fig. 8 shows an overview of the PGP 
exchange. The exchanges proceed in three phases: com- 
mand, data, and status 

SCSI Exchange State Table. The s< SI exchange state table 

amnion -based data structure. Art ess is shared between 
TaChyon and the host The S< SI exchange state table is an 
array of 32*byte entries, The starting address of the table is 
programmable and is defined by the SCSI exchange state 
table base register. The length of the table is also program 
mablc and is defined by the SCSI exchange stale table 
length register. Bach used table entry corresponds t# a cur- 
reut S< SI exchange, or I/O operation. Each w\iry contains 
iwu kinds of information: information supplied hyiliehosi 
driver for Tachyon to manage the exchange, and information 
stored by Tachyon to track the current state of the ex- 
change. For initiators in SCSI write transactions! the otri 
bound SCSI exchange state luble entries contain informa- 
tion indicating where outbound dam resides in memory and 
what paraiiH -u m to use in thr transmission of that data on 
i lie Fibre ( hannel link. For initiators in srsi lead transac- 
tions, the inbound . SC SI exchange stale table entries contain 
information indicating where inbound data is in be placed in 
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memory, SCSI exchange state table entries are indexed by 
an exchange identifier (XJD) — either the originator ex- 
change identifier (OXJD) or the responder exchange idenii ti- 
er (RXJQ). hi an initiator application, the OXJD provides the 
index into the SCSI exchange state table In a target applica- 
tion, The RXJD provides the index into the SCSI exchange 
state table. 

FCP Read Exchange — Tachyon as an Initiator. Fig. 9 shows the 
FCP read exchange host data structures for an initiator Ta- 
chyon. For the initiator host to receive inbound SCSI data, it 
selects a valid OXJD value that points to an unused location 
in the SCSI exchange state table. The OXJD value identifies 
this particular exchange. Using the OXJD value, the initial or 
host builds a data structure called an inbound SCSI ex- 
Change state table entry. The inbound SCSI exchange state 
table entry includes the address of the SCSI descriptor 
block. The SCSI descriptor block defines the host buffers 
that Tachyon will use to store the received read dala. 

In the command phase, onee the host creates the inbound 
SCSI exchange state table entry, it creates an FCP^CMND for 
an FCP read exchange. The initiator Tachyon sends the 
FCP_CMND to the target via the outbound command queue. 

hi the data phase, the initiator Tachyon may receive an 
FCP_XFEH_flDV from the target. This is an optional step for an 
initiator in an FCP read because die data frames contain all 
the information needed to process them. When Tachyon 



receives the Optional FCP_XFER_RDY from the target, it ac- 
knowledges i he frame if appropriate and discards the 
FCP_XFER_RDY. As each data frame is received, the SCSI ex- 
change manager uses the OXJD to access the appropriate 
\\\}}i niiid SCSI exchange state table entry for the address of 
the SCSI data hulTer. The SCSI descriptor block and the rela^ 
Live offsei of the data frame determine where data is to be 
placed in host memory. Tachyon maintains an internal cache 
of to inbound SCSI exchange state table entries. If the SCSI 
exchange si;n<> table information associated with the re- 
ceived frame is not in cache, Tachyon writes the least re- 
cently used cache entry back h> the host SCSI exchange 
state table. Tachyon then fetches inl<> Cache the inbound 
SCSI exchange state table entry associated with the re- 
ceived frame and transfers the read data to host memory via 
DMA. The initiator Tachyon automatically handles both 
single and multiple data phases for inbound data transfers. 

hi the status phase, when the data phase is complete, the 
initiator Tachyon receives an FCP_RSP from the target. The 
FCP_RSP is a Fibre Channel information unit that contains 
status information that indicates that the SCSI exchange has 
completed. The initial or Tachyon passes the FCP_RSPto die 
host via the single-frame sequence channel and sends a com- 
pletion message to the initiator host. This informs the initia- 
tor host that the exchange is completed, 

FCP Read Exchange — Tachyon as a Target For FCP read ex- 
changes for the target Tachyon. SCSI hardware assists are 
not used. Fig. 10 shows the read exchange target host data 
structures. 

In the command phase, I he l&rgel Tachyon receives an 

FCP_CMMD for an FCP read from the imitator and sends the 
FCP_CMND to the targei host via the single-frame sequence 
channel. If configured to automatically acknowledge, the 
target Tachyon immediately returns an ACK ( lor class 1 and 
class 2) to I he initiator. The target host selects a valid, un- 
used RXJD value. The RXJD is placed into the header of the 
ACK and sent via the high-priority command queue. 

In the data phase, the target host builds an outbound des- 
criptor block that contains the extended descriptor block 
address. The target host builds an extended descriptor block 
that defines where the read data is local ed in the target host 
memory. The target host may send an FCP_XFER_RDY to the 
initiator host to indicate that it is ready to send the re- 
quested data. The target Tarhvuu sends flie BCf Xfffl B§Y(s) 
with the appropriate RXJD value to the initiator Tachyon, 
I sing the outbound command queue, the target Tachyon 
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then sends the appropriate S( SI read data to the initiator via 
the outbound command queue. 

In I he status phase, the target Tachyon sends an FCP_RSP to 
the initiator to Indicate ihai the exchange has completed, 

FCP Write Exchange — Tachyon as an Initiator Pig. 1 1 shows the 
FCP write exchange inhiana host data structures. Konhe 
initially host to perform an outbound data transfer, it selects 
an unused SCSI exchange state table entry whose index will 
be used as the OXJD value. Using the OXJD value, the initia- 
tor host huilds an outbound SCSI exchange state table entry. 
The outbound SCSI exchange state lable entry includes in- 
formation about the frame size, the Fibre Channel class, and 
writable fields that the initiator Tachyon uses to manage the 
S( SI transfer. The outbound St SI exchange state lable entry 
also contains a pointer to the extended descriptor hlo< k thai 
contains pointers to the data to he sent. 

In the command phase, oner Ihe host creates the outbound 
SCSI exchange slate table entry, the host ctcau-s the 
FCP_CMND for an F( T write exchange. The initial or Tachyon 
sends the FCP_CMMD in Ihe target via the outbound command 

<|1ICUC* 

In the data phase, when Hie initiator Tacfayon receives the 

FCP_XFER_R0V from the target, it uses its SCSI hardware as- 
sists and manages the data phase for this FCP_XFER_RDY inde- 
pendent of the host Tachyon uses Ihe information in the 
sc si exchange state table and Die FCP_XFER_RDV hi build an 
outbound descriptor Murk to be seiil through Ihe outbound 
state machine, [f the outbound sequence manager j* busy, 
ili" SCSI exchange stale machine adds the request to a 
linked lisl of outbound truusaciions waiting for transmis- 
sion. As the (nit lion Hi I sequence manager becomes avail 
to process a SCSI transfer, the- SCSI exchange stale manager 
dequeues w wailing transaction and passes il lo the out- 
bound sequent manager. The outbound sequence manager 
transmits the write data tO the target Taehyuii, 



If this FCP_XFER_RD - x a mul tiple-dai a-j >hase t rai \ - 

the initiator Tachyon passes this FCP_XFER_RDY as a single- 
frame sequence to die initiator host along with a completion 

sage, The initiator host is resr> maible for managing the 
data phase for this muhiple-data-phase transfer h> using the 
general sequence moving services. The OXJD Held in ihe 
FCP_XFER RDY is an index im . Man table 

and identifies the appropriate \ unbound S( 'SI exchange 
state lable entry that points to the extended descriptor 
block in which the w-rite data is located, I sing the informa- 
tion in the outbound SCSI exchange state table entry the 
initiator host builds an outbound descriptor block. The initi- 
ator Tachyon uses the out hound descriptor block to trans- 
mit the write data lo the target. 

In the status phase, after the data phase completes, the initi- 
ator Tachyon receives an FCP RSP from the target. Hie initia- 
tor Tachyon passes the FCP RSP lo the host and sends a Com- 
pletion message to the initiator host. This informs tin 
initiator host thai the exchange has completed. 

FCP Write Exchange— Taehvon as a Target. Fig, 12 shows the 
Ft V write exchange target host data structures. 

In the command phase, the target Tachyon receives an 
FCP_CMND for an FCP write from [he initial or. If configured 
to do so, the target Tachyon Immediately returns an ACK to 
the initiator for class 1 and class % If Tachyon is not con- 
Bgured to return an ACK, the target hosi is responsible foi 
sending the ACK. The target host selects a valid RXJD value, 
places ihe RX ID inlo the ACK header and sends the ACK via 
the high-prioritj cornmand queue. 

In the data phase, the target hosl selects an unused St SI 

exchange state table entry whose Index will be ihe RXJD 
value. DsingtheRX 10 value, the target host builds the in- 
homul SCSI exchange slate table enl ry dial poiuls to (fie 
St SI descriptor block. The SCSI descriptor block contains 

as many buffer addresses as necessary to receive the data. If 
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the target host has enough buffers and is ready to receive all 
of the data from the initiator, the host programs the inbound 
SCSI exchange state table entry and the target Tachyon 
sends the FCP_XFER RDV to the initiator via the outbound 
command queue. The initiator will send I he data when it is 
ready. 

The target Tachyon checks the RXJD of the data frame to 
locate the appropriate inbound SCSI exchange state table 
entry- The inbound SCSI exchange state table entry helps 
Tachyon determine exactly where within the buffers die 
data is to be placed. When the last data frame is received, 
the target Tachyon sends a completion message to the target 
host to inform the target host that all frames for I he SCSI 
sequence have been received. 

In the status phase, die target host sends an FCP_RSP to the 
initiator via the outbound command queue. 

Tachyon System Interface 

The Tachyon system interface describes the backplane pro- 
tocol for the Tachyon chip. It is a flexible backplane inter- 
face that allows customers to interface to Tachyon using 
many existing backplane protocols, including PCI, MCA. 
S-bus, EISA, VME t and Hewlet I -Packard's High-Speed Con- 
nect (HSC ) bus. The Tachyon system interface is capable of 
100-Mbyte/s data Iransfers. Fig. 13 shows the Tachyon sys- 
tem interface signals. 

The Tachyon system interface provides a basic transaction 
protocol that uses two major operations: write transactions 
and read* transactions. Every transaction has a master and a 
responded If the host is the master of a transaction, Tachyon 
is the responder in that transaction, and vice versa. 

The master of a t ransaction drives an address and transac- 
tion type onto the TADf 3 and TYPEl J buses, respectively, while 
asserting AVCS_L to indicate the start or the tratisaction. If 
Tachyon masters a transaction, the host, as the responded 
uses READY _L as its acknowledgment signal. Similarly, if the 
host masters the transaction, Tachyon, as the responder, 
uses READYJ. as its acknowledgment signal. A Tachyon sys- 
tem interface bus master has the choice of using one-word, 
two word, four-word, or eight-word read and write transac- 
tions on the Tachyon system interface bus. 

Tachyon System Interface Streaming 

To maximize performance, the Tachyon system interface 
allows the host to configure the length of Tachyon s bus ten- 
ancy. When Tach vun obtains mastership of the Tachyon sys- 
tem interface and has more than one transaction to perform. 



Tachyon may extend its bus tenancy and perform several 
Tachyon system interface transactions (up to the maximum 
programmed limit) before releasing mastership. Table I 
shows how streaming increases performance over non~ 
streaming. 

Table I 
Tachyon Performance Savings with Streaming 
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Tachyon Host Adapter Requirement* 

A generic Fibre Channel host hus adapter board using the 
Tachyon chip contains the following: 

* Backplane Connector. Connects the backplane interface 
chip to the system bus. 

♦ Backplane Interface Chip- Ekiables ilk- connection of the 

lis to tXt EISA, HP-HS* 
other has. 

• Tachytm Chip, ffl 'haiuid b 

• Physical Link Module. Tachyon ititei I 

compliant physical link modules currently in the market- 
place. Types of modules include: 

1063-Mbit/s DB9 copper connectors for distances up to 

:J0 meters. 

1063-Mbit/s shortwave laser physical link modules for 
i|< to 'on meters, 

1063-Mbit/s longwave laser physical link modules for 

distances up to 10 kilonn 

•jw\ \n mi 'K^liMiiwave [asn physical link modules foi 

disiances up to li kilometers, 

A block diagram of a typical host bus adapter is shown in 
Fig. II. An IIP-MSt ; Fibre Channel adapter is shown in 
Fig. 1 5. This adapter was developer! by IIP to provide Fibre 
Channel connection to the HP 9000 K-Hass servers 3 for fast 
networking and mass stora# 
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Fi^. 14, Block diagram of a typical host adapter board. 

Development Tools 

Effective Ixm ds were key to the success of the Tachyon 

chip, 6 The following tools were used in the development 

project 

1 ai fence VerilogOCL Turbo was used for interactive and 

batch Register Transfer Language (RTL) simulations, gate 

functional simulations, and dynamic simulation. 

Chronologic Verilog Compiled Simulator (VCS) was used for 

\ >a t c h RTL si m i ilat ions 
1 Quad Motive was used Tor static timing analysis, 
1 Synopsys was used for chip sym i i 
1 Veritools Undertow was used as a waveform view er. 

lute] -I IUL Verilint was used in check syntax and semantics 

tor RTL code. 

SIL Synth was used to manage and launch synthesis johs. 

History Management System i HMS) . ■ written by Scow A. 

Kr; uner. was used as a fi'Vist-m control system. 
LSI Logic Corporal ions Concurrent Modular Design Envi- 
ronment (CMDE) was usvd Foi Rootplaiuiing bonding* delay 
calculation, and layout 

Hewlett Packard Task Broker 6 was used to distribute jbhs 
to ihe various compute engines. 

Verification Environment 

The verification envirimnu-rii used for Tachyon was \ cry 
sophisticated and automated The Tachyon chip model (as 
either a Verilog RTL code or a gate fe\<l netlist j was tested 
in simulation using Verilog's programming language inter- 
im e capability Test modules written in G or in Verilog pro- 
vided stimulation to the Tachyon chip. Other test modules 
i hen verified the functionality of the chip and reported 

errors. 

Conclusion 

The Tachyon Film* l 'lianncl inn riace controller provides a 
high-performance, single-chip solution for mass storage, 
clustering, and networking applications Tachyon has been 
selected by mans othei companies as the cornerstone of 
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their Fibre Channel product designs. As an understanding of 
die capabilities of Fibre Channel technology grows in the 
marketplace. 1 achy on is expected to be present in a large 
number of new Fibre Channel products. 
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